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1 . 1 £R££4a£-IQ-E£MISIQi-l-ia£MIS£ll-.£6^iiaiX«12ail 

Approved SIS DAPs Incorporated In this revision ares 

S4646 - Revised GX80 Coiion Pararpeter list Foriaat (John Barney) 

< Major changes to section 5«2) 
S4658 - Add Deck Classes A and B CPete War-burton) 

S475.3 - Correct Dialog Parameter (Alan McHahan) 
S477§ ~ Change Prodyct ID for BASIC (Bruce Kenner) 

1.2 S£^I£Miti£^4Ma-U£aiIltlll-iaii«IlQ£yE£MI 

The 'CI60 SIS has been thrisugh a number of review cycles and has been 
forfflally approved by the C180 Baseline Change Control Board (BCCB)« 
It Is thus considered fairly solid. 

However # It Is recognized that the SIS Is a living document with a 
continual ne-e^ for updating. Please follow the following guidelines 
in reviewing and updating? this docujients 

1» llPilt coiiiients or updates to question of Inaccuracy* lack of 

coffspl etenessf or necessary technical change* Avoid questions 

of personal preference. 

2. For relatively ^Inor probfe?^s or questions resulting frotp a 
norfflal review^ a normal DCS comment Is appropriate. it is the 
responsibility of the appropriate author Cs) to resolve the 

coiPient-t 

3. For more major updates that may be somewhat controversial* a 
stand-alone DAP Is appropriate. This allows a thorough review 
of the issues Involved. When approved* the DAP will be 
Included In the next SIS update. The SIS referee or editor 
should be Informed of any plans to submit such a DAP and the 
DAP should be in the fornn of a proposed SIS update. 

4. There will be occassional "minor review cycles** of the SIS to 
Incorporate minor changes a.n4 previously approved DAPs. 
Authors may make minor changes to their sections at this time 

^or review and approval. 
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1«0 SEVERAL 
l.*3 CHARTER 



1.3 aMMIIE 
1.3.1 PURPOSE 



The purpose of t^^is standard Is to ensure a uniformity 
across tlie operating system and product set that mIII make 
the total system roore easily usable and huwan engineered. 



1.3.2 SCOPE 



This standard covers product-to-product* product-to-user* 
systam-to-user» and pr oduct-to-oper ating systesi Interfaces* 

Any external Interface which Is not defined by an Industry 
standard may bs defined In the System Interface Standard. 
In order to achieve a unlfornsity across the product set# 
certain Internal Interfaces shall be Included In this 
standard* e.g. calling sequences. 

The product set Includess 

The Coriollers* Interpreters* and Assemblers 

Data Hanigtment Products 

Ut i I I ties 

Source Code Maintenance 

The operating system Includess 

Basic operating systen? (nionitor* I/O drivers* systen? 
startup* ooerator cowiipunl cat Ion* permanent file 
luanager* etc). 

Loader 

Record Manager 

Coma5and Language 

Networks and Interactive Product 

On-Llne Maintenance Software 

The "system" Includes: 

The operating system 
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1.0 GgHERAL 

1.3 ,2 scope 



1.4 MiLI 



The product sat 

The specific goals of tbe System Interface Standard ares 

a. Consistency within and across the system • 

b* Human englnsared for user. 

c* Acliievable within CYBER 180 timeframe. 

d. Good performance. 

8. External Interfaces like CY170 wliere this does not 
conflict with a> bf c and d above. 

There fiust ba «ore than trivial gain In aspects of human 
engineering to cause deviation frora CY170 external 
Interfaces. 
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2.0 INPUT 



z*o imui 



This section dascribes the standard and conventions for 
Input to products* Input standard Is defined for Systap 
Coniiand languaia* Control Statement* source file 
organization and contents* 



z . 1 siii£M>caia^ii^«iM£y4aE 



The System CoiBnand Language Is the set of language rules 
and conventions to be followed by any software product 
that presents a user Interface Cwhich Is not defined by an 
Industry standard). It Is documented In the NOS/VE ERS 
<DCS docyrpents ARH3609# ARH3610)* For examplef conmands 
to call products* and operator comwands *«l 11 conform to 
this language definition* It Is a requirement that all 
products use the standard coflimand language routines to 
process systei command language statarnents <such as 
product call comn^ands or product directives). The Intent 
here is that products do not duplicate code or functions 
already provided by standard oomm^n^ language routines. 
See HOS/VE ERS CARH3610) for a description of these 
routines* 



2*2 £Eai2yCI-CALL-.CQMIlMai 



This standard specifies the parameters which can be used 
in cofflfijands that call CYBER 180 products* The syntax of 
the command is documented In the NOS/VE ERS* 



2*2*1 4PPLICA8ILITY 



This section specifies all paraiijeter names* descriptions 
and defaults o^ parameters on a command that calls a 
product* Raqui r efT?ent s for use of the parameters are* 

« If a product offers a capability which is the same as 
one defined In this standard* then the specification 

in this standard juust be used. 

* A product Is not permitted to use a parameter defined 
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2. 2.1 ^PPtlCABIllTY 



fey tiie standard for a purpose other than that 
specified by the standard. 

. k product r^eed not implewient ail the par aijet ers or alt 

the parts of a paramater In this standaril. 

• New parai!i8tar nanies or options must first fee approved 
as additions to this standard. 

» A product lay support as many aliases as defined for 
the parameter. However j If a product provides a 
function described fey the parameter In this standard* 
the described parameter nape and its aliases must be 
supported by the product as a minimum^ 

Some guidelines for proposing ne*« paraipeter names and/or 

options ares 

1. Use a new option of an existing parameter rather than 
a new para-i^eter name if the capability is an extension 
of an already defined parameter {exaiiplei use D«DS 
instead of inventing a new paraiueter DS for debug 

statements .^ 

2. For related par anieter st use aliases that emphasize the 
relationship {examples 10 to relate listing options to 
the list file, L) . 

2.2.2 TERHINQLOGY 

Defaults The value used for a parameter when the parameter 
does not apoear in a command. Section 4.3 on installation 
parameters Indicates which paraffseter defaults are 
installation changeable. The defaults specified In 
section 2.2.4.2 are those expected to be most often used* 

2.2.3 SYNTAX 



The syntax of the command is defined In the NOS/VE ERS* 

If a parameter Is omitted* default values are used. Use 
of <pararoeter name « OFF> results In turning off a single 
option parameter or boolean single specified value 
parameter. Use of <parameter name> « NONE indicates that 
a specified value Is not supplied for a multiple value or 
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2.0 IHPilT 
2,2*3 SYNTAX 



iiyltlple optiori parameter (for exaiiplet 10 « NONE causes 
f^one of the list options to foe selected)* 

Mlien the parameter valye is a file name* the file f^ame 
$NUIL should be used to negate that file {for exaniplef 
B'SHULL causes the product not to produce a binary object 
code file), $^1111 Is a reserved file name* A read will 
respond Mlth an end-of-inforiuati on* SHUtl Is an Infinite 
sink for nrltes* 

The follOMln<i tigorlthw Is applied to partmetersi 



1* Inltlallyf all value options for this parai^eter are 

considered deselected (l*e* there are no Initial 
va lues) • 

2. Only the optfonCs) specified in the ¥alue list are 
then selected* 

The <na«ie> used on the com>f$and to call a product can be 
either an alias or a long form as follows: 



A I I as 

API 
BASIC 

CC 

COS 01 
CY3IL 
EDIF 
EOIl 

FMU 
FTH 
LISP 
PASCAL 
PL I 



Long Fortn 



EOIT.FILE 
EOIT.LIBRARY 



FORTRAN 



Description 

a programming language 

beginner's a 11 -pur pose symbolic 
Instruction code 

The language C 

consmon business oriented language 

Cyber Implementation language 

Edit Screen (for raw text) 

Edit Screen (for Source Code 
Utility libraries) 

file management utility 

formula translation 

I 1st processor 

PASCAL (wirth) 

programming language I 



2-4 
CY8EI? 180 System Inttrface Standard 

84/07/2? 

2.0 INPUT 
2.2.3 SYNTAX 



Q.U qyery update 

SCU source code utility 

SORT sort 

MERGE fflerge 

¥X UNIX systeiu eiulator 

2.2.4 PARAMETER 

Qccyrrance of tr^y parameter niore than once In a control 

stateliest Is an trror* 

2.2.4.1 Efisitiaaai-aLdaLlQa-Oi£-££Qdu£t-S£l:«£ j£Jist£LS 

Product set members providing the I# 8^ and I paranieters 
fpyst support the folloMlns positional ordering on a 
non-keyword call. There is no guaranteed coiMon ordering 
of other parameters to a product set ntember except what 
Plight be documented In the reference manual for that 
product. 

1. INPUT 

2. BINARY rnornjally the iriain desired output of a coippller) 

3. LIST 

2.2.4.2 I^£fi.ai.£li:^!2SttLa 

See the ConiPand Interface (Part I) of the NOS/VE ERS for a 
description of the file reference* which is the syntax to 
be used for specifying a file name as a parameter value. 
If no position Is specif I ed> the product will reposition 
the file before use as followsi 

a) for a file named $IHPUT# no repositioning will 
take place If the file Is at beginning of 
Inforiiat lon# at end of Information* or at a 
partition boundary. Otherwise* It will be 
repositioned to end of partition before use. 
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2*0 INPUT 

2»2«4*2 Types of Parifneters 



fe} for t fjis naiped SQUTPUTf the product mlii do 
repositioning before use. 



no 



c) for at! other flles> tlie pr odycts will reposition 
to beginning of inforipation before use* 

ExaispIeJ If a cali to SCU has been made to write three 
source decks ti COMPILE {the first FTH# the second CYSIif 
the third FTN) and they are to be compiled with the object 
code placed on file LGO* the $ASIS positioning roust be 
specified <?n the second and third compilations since 
default positioning is rewind* 



FTN 



I»C3HPILE 



CY8IL I«CaHPILE*«ASIS#8«LGQ*$ASIS#l«$0yTPyT 
FTN I»CQnPIL£.$ASIS^B«LGO.SASISfL*$QUTPUT 

There are four kinds of paraaietersJ 

U) Single Specified Value 

This is a parage tar for which the user must specify a 
value* such as a file reference or a boolean as In the 

for jis 



Keyword - 
wheres 
<bool ean> 
<true> iJ 
<false> s 



<booi ean> 

: : « <true> I <f alse> 
» TRUE I YES I OH 
= FALSE ! NO I OFF 



be 



for 



For the sake of consistency the values ON and OFF will 
used In this document* Products may choose any of the 
values for <triie> and <false> desired and describe the 
choices as such In the product docuj^entat i on. The 
operating system will accept the values for <trye> and 
<falsa> equlvaiantly when the standard conifnand language 
routines for the control statement processing are used* 
As a result* users will be able to enter any of the values 
for <true> or for <false> without regard for what values a 
product has chosen to docunient* 



(2) Multiple Soecifled Value 



This is a parameter for 
file references) may be 



which n?ore 
speci f led* 



than one value 
The form 



(such as 



2-fe 
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2.0 INPUT 

2«2«4.2 Types of Paran^ters 



<para?j?eter-f^aia » NONE> n\\\ fee used to indicate that none 
of the available options for a parameter are desired. 

(3) Single Option 

Tills is a parameter f<jf *#hlcli the user specifies 

<optlon> - ON 

14) Hyltlple Option 

This Is a parameter for which the yser may specify the 
na«ies of raore than one option* 

For pyltjpis specified value parameters the value list 
syntax Is as described In the HOS 180 ERS* Part I section 
"Parameter Lists and Types", k value list consists of a 
series of value sets separated by one or isore spaces qt by 
a single cofifia. When nore than one value set Is 
specified* the list must be enclosed In parentheses. A 
value set consists of a series of values separated fey one 
or nore spaces or by a single cofRflia. ^h%n more than one 
value Is specified the set must be enclosed In 
parentheses. The rule Is that an outerniost pair of 
parentheses belong to a value list and Inner pairs of 
parentheses belong to value set. 

The for^ <par a^neter name = NON£> will be used to Indicate 
that none of available options for a paraiiieter are desired. 

2.2.4.3 £a£ai£t£JL-tiaffiaa>aail-[l£S££i£tiiiQS 

The pararaeters are described In alphabetical order. 
Parameter 

Na?!ie Alias Parameter Description 

AUDIT AUD This parameter is used to indicate that 

the product Is being run for audit 
testing. The parameter causes the 
selection of any other parameters «hlch 
f?5ay be needed for audit testing zs well 
as selecting the method of processing* 
which may differ from normal processing. 
Each product inust provide a list of I terns 
affected by the AUDIT parameter. For 
example* In COBOL the list of I terns might 
include the mode where displays of 
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Z.Q INPUT 

2«2.4*3 Parameter Naies and Descriptions 



BINARY^OBJECT 



nymaric iteros would not be etilted* 

Single option parameter* OefaultJ the 
option Is not selected* 

AUDIT « ON selects this option. 

B Binary Object code oytput file* 

S « <file> 

Tills parameter specifies the file to 
contain the object code or text produced 
by a GOfspller or assepisler* 

8=$NUIL indicates that no such binary 
object code output file is to be written* 

Single specified value paraieter* default 
= $LOCAl*LGO 

COllATING.SEQUEHCE^X SEQX Collating sequence {X « Name or N# Step 

or S* ReR^ainder or R# Alter or A)« The 
parameters SEQHj SEQS# SEQR and SEQA 
control definitions of collating 
sequences for an applicable product* 

SEON* The S£QN paratseter signals the 
start of a collating sequence 
definition. The definition of one 
collating sequence continues with SEQS# 
SEQR> SEOA parafnetersj It Is terminated 
by any paran?eter not one SEQS* SEQRf 
SEQA* The form is? 

SEQN a <nai!ie># «here name Is the name of 
the collating sequence* 
SEQS* Each SEQS paranraeter specifies 
either a single step or a range of 
steps* The forfn is: 

SEQS = <va lue-l ist>> where the 
expressions in the value list are 
character expressions* 

SEQR* This parameter specifies all 
characters In the character set not 
specified In a SEOS parameter* explicitly 
or implicitly* The form is? 



CY8ER 180 Systesi Interface Stan<iard 



2.0 INPUT 

2.2»4«3 Paraiiettr Haanas and Descriptions 



SEOR 



ON 



SEQ4. This parameter may be specified 
alter all e<iuated characters In output 
records so tliey become the first 
character In the appropriate SEOs 
parameter* The form Is' 

smh « ON, 




COLUHNS 



CQHPIIE 



COL This paraaseter specifies three valuesJ 
starting and ending colunins containing 
source and coIuiph containing a directive 
to the product Ceach product for which 
such a directive is supported *«ill define 
the weaning of the information In Its 
directive colunnl* For example* PL/I pay 
define the directive coluran as containing 
a print carriage control character* 

Single specified value list? default « 
Clfn) where n Is language dependent* 

C Coinplle file* 



This parameter specifies 
on which conpiler source 
written* Examples ^rei 
produced by a conversion 
updated source output by 
maintenance utility for 
assembler or copoller* 



the output file 
statements are 
the output 
aid uti I Ityj the 
the source 
input to an 



Single specified value paraaieter* 
default « COMPILE* 



COHPILATION. 
DIRECTIVES 



C170.C0HPATI8LE 



CD If selected* coiwpllatlon directives (see 
SIS section E*4) will be recognized* 
Otherwise compilation directives will not 
be r ecognl zed— If directives are expressed 
as a special form of comment they will be 
treated as are all other comsnents* 

Single option parameter* Default » ON* 
directives are recognized* 

CC If selected* all possible CYBER 170 to 
CYBER 180 product differences will be 
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2.0 INPUT 

2.2 #4 •a Paran^eter Nttiies and Descriptions 



DEBUG 



converted to tfie CY180 version or 
diagnosed nith aiessages* For example* in 
COBOL iteffls specified as COMP-4 will be 
assumed to be CQMP» All products will 
provide a list of such conversions or 
assufflpt Ions* 



Single option parameter, 
option Is not selected* 



Defaults the 



C170.CQHPATIBLE « ON selects the option* 

Debugging option 

This parameter specifies the debug options 
to be selected* Ail products need not 
support all options* Multiple options may 
be specified* The defined options ares 

DS Debugging stateients. All debugging 
statements will be compiled* A 
debugging statement is a statement In 
the source which Is ignored by the 
product unless this option is 
specified* Debugging statements 
usually specify debug actions for the 
Piodule containing them* See also 
section 2*4*7 of this standard* 

NC Mo checking* Do not generate 

parameter checking information as part 
of the object code* Unless NO Is 
specified* all compilers which support 
checking will generate actual Informal 
parameter description Information In 
the object code to enable load-time 
detection of parameter mismatches* 

NT Wo tables* Do not generate line 

number and symbol tables as part of 
the object code* Unless NT is 
specified* line and symbol tables are 
generated on all compiles* 

OC Object code regardless* Produce 

object code* regardless of errors In 
the source and severity of such 
errors* For compilers* execution of a 
line containing a fatal error should 
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Z*Q INPUT 

2»2#4«3 Parameter Naiies and Descriptions 



DEFAULT. C01L4TI0N 



DIRECTIVES 



result ill a call to an object tiiae 
routine which *iill terisinate the 
axecutlon with a message* (See 
section 3*4 for error status returned*! 
Products yith no object tlae library 
fsay generate a -jL^tt^ C program error) 
instructon for lines In error* 

TR floM tracing* Activate trail progiats 
In the source prograra* Unless TR Is 
specified* trace progmats have no 
effect* 



Fiultlple option parameter* 

NONE 



The default Is 



OC This parameter specifies the weight table 
to be used for the evaluation of character 
(string) relational expressions and to be 
used by intrinsic functions which are 
collated sequence dependent (for exajnple 
CHAR and ICHAR In FORTRAN)* The defined 
options are? 

y Qt USER 

A user specified weight table Is 
used* In FORTRAN a collection of user 
callable procedures is provided for 
manipulating the user weight table* 

F or FIXED 

A fixed (unmodlf i abl e) processor 
specified weight table Is used* 

Single specified value parameter^ 
default = FIXED* 
DIR: Direct I ve Fi le. 

Additional parameters will be read frosj 
this file after all of the control 
stater??ent parameters have been read* 



DIR* f I I e-name 

Pararaeters will 
f I le-naroe • 



be read froffi file* 



DIR* (f i le-namel£#f i Ie-narae21 * • .) 
Paraweters will be read from the 
flies in the order that they are 
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Z»Z*^*3 Parafneter Ntfiias arid Oescrlptlons 



HultlPle sp#cified value parameterj 
defaylt » HO AODITIONAl PARAHETERS ARE 

READ. 

ERROR 5 Error File. 



This paranieter specifies the nape of the 
file to receive error llstli^g 
inf orwatloo. In the event of an error 
{of El specified severity or higher) the 
diagnostic is written to the E file. It 
Is highly recoiiisencled C though not 
required) that a product also output the 
offending source line or lines to the E 
file in conjunction Mith the diagnostic. 
If there is a listing file {see I 
parameter) the error line and diagnostic 
are also written to the L file. If the 
file name of the E flie Is the same as 
the file naisie of the I flle# then the 
error line and diagnostic are not written 
twice. 

Single specified value parajaeter* 
default * the listing file specified by 

$ERRORS 



ERROR.LEVEL EL Error level 



This option Indicates the severity level 
of diagnostics to be printed on the 
user's listing. The levels are ordered 
by Increasing severity. Specification of 
a particular level selects that level and 
all fnore severe levels. Products i<till be 
allowed some flexibility in specifying 
the kinds of diagnostics that fall In 
each of the six catagoriesi 
non-standard* itachlne dependent* trivial* 
warning* fatal* and catastrophic* The 
following descriptions are provided as a 
guide. 'The product's status parameter 
will be set according to the value of 
terfu I nation error level CTEl)** The 
levels In Increasing order of severity 
are t 



CY8ER 18© Sfsteii Imtarftca Staiidtrd 



84/07/27 



a. CI INPUT 

2»3.4.3 Paraiietef Naies and Descriptions 



ESTIH,ATE0.NyM8ER. 

RECORDS 



ENR 



f Infisriiat lonal .. This Is an 

Informational a?essage used to flag a 
suspicious usage* The syntax is 
correct but tlie usage Is 
<iuest ionable. For 170 compatlbl I i ty# 
prcducts Qre free to use »T' in 
addition to 'I'* However # output 
Hill always be •!'* not *T». 

U Warning* Tbis is a diagnostic «iiere 
the syntax is incorrect but the 
product has pade an assumption (such 
as adding a commn) and continued* 
Hessages indicating atteiupts at error 
recovery are at this level. 
Diagnostics of M level should be 
errors that the user can avoid by 
prograip modification* 

F r-atai* This ks a diagnostic which 
prevents the product from processing 
the statement In which it occurs* 
Unresolvable semantic errors also 
fall into this class* Such errors 
wiay not relate to a specific 
statement In the prograip unit* 
Errors of type « ERROR » will be 
treated as equivalent to •FATAL'. 

C Catastrophic. This class of error is 
fatal to continued processing* The 
product Is unable to continue work on 
the current program unit* However* 
It should still advance to the end of 
the current program unit and attempt 
to process a subsequent unit (If the 
product specif I caton allows multiple 
program units in a compi I at loni • 

Single specified value parameter* 
default « W* 

EL*NOM£ causes no errors to be listed* 

EstlPiated Number of Records* 
This parameter specifies the estimated 
number of records to be processed by a 
product* For exaropie> SORT can use It to 
cause selection of efficient modes of 
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2.0 INPUT 

2«2«4.3 Paraneter Hamas and Descriptions 



EXCEPTIQM 



EXPRESSION, 
eVAlUATIOH 



process I ng« 

Single specified valye parametert 

default « 80000/HRl* 

EXC This Is a file containing exception 

inforpation. Products will be allowed 
flexibility In defining Its contents* 

For ax amp I e# SORT HERGE will use It for 
oyt-of-order merie input records* 

Single specified value paraipeterj default 
Is product dependent* 

EE The options of this parameter control the 
style of code generated for the 
evaluation of source expressions* Note 
that the processing controlled fey this 
para»neter Is separate froi that 
controlled fey the optimization level 
paraiieter^ but way affect the extent to 
which optimization is possible* The 
def I ned options are: 

C or canonical 

The code generated to evaluate an 
expression will iplrror the expression 
Interpretation rules as defined in 
the product specification* For 
FORTRAN this would be section 6 of 
the ANSI standard* This option also 
serves to Inhibit the CCG •*regroup»» 
opt i on. 

HE or mainta in^exceptlons 

Inhibit code optimizations which 
eliminate instructions that snight 
cause hardware exceptions at 
execution time* This option also 
serves to inhibit the CCG 
"unsaf e^to.saf e'* option* 

MP or maintain.precision 

Inhibit code optimizations which 
change a floating point operation to 
a new form that is mathematically 
equivalent but not computationally 
equivalent. This option also s%t^%^ 
to select the CCG "maintain. 
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2.0 INPUT 

2*2«4*3 Parameter Names and Descriptions 

precision*' option* 

R or reference 

Intrinsic fynctlons Ce*g# those 
defined in CHHi) for which a 
procedure call Is generated will be 
called by reference rather than by 
value* 

l^ultlpie option parai«€ter« 

Default * HONE* none of the options Is 

sel acted* 

EXTERNAL. INPUT^ EX. External input file. 
FILE INP'JT 

This file Is for use by products which 
provide the capability of teiBporarlly or 
alternately obtaining source statements 
from a file external to the Input file* 

For exaraple# the COBOL COPY statement* 

Single specified value parameterl 

default « SNUll* 

FORCED. SAVE FS If selected* the definition status* of 

all entities within a sub procedure of a 
program will be retained upon exit from 
that subprocedure* Effectively this 
disallows placing any variables on the 
stack* 

Single option parameter. Default « OFF* 
definition status need not be retained 
except where so required by the product 
spec I f icat Ion* 

F'ROH Old file* 

This parameter specifies the data Input 
file for the product* For example: the 
file froii which a copy utility reads* 

Multiple specified value parameter; 
default * OLO* 

INPUT I Input f I le* 

This paraRieter specifies the source input 
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2»2«4,3 Parameter Names and Oescr ipt lo^ns 

file r^awe to tfie product. 

Single specified value paraiieteri 
defauit « SINPyi, 

INTERACTIVE. Id# This parar^eter deterroines whether the product 
OIALOSIIE dialog* Mill Initiate an Interactive dialog *«lth the user* 

dia Intead of operating in Its usual batch-or I entad 
fashion. Tills dialog consists of questions and 
explanations written by the product to file $QUTPU 
and of user-supplied answers read frop file SINPUT 
The dialog can be Invoked either froro an Interact! 
teriilnal* or a batch Job. 

Single option boolean parameteri 

Y£S This choice initiates the dialog* All oth 
parasieters on the copsiand line way 
be Ignored except STATUS. 

NO Do not Invoke the dialog. 

oifilttsd Same as HO. 

KEY Key FleldCs). 

This parameter specifies the ffey fields 
that determine the manner in which input 
data flight be processed by a product. 
For example* SORT will use the parameter 
to determine the order records will be 
sor ted. 

KEY«<valye-l lst> 

The value list will contain one or 
more value sets. The resulting 
output will have been processed 
according to the key field described 
by the leftinost value set. Input 
data with equal values for this key 
field will be processed according to 
the key field described by the next 
value set* et cetera. 

Multiple specified value parameter* The 
default value set specifies 



key«l*«fflnrf where mnr is the 
smallest of any HNR on a FILE 
control statement for Input files. 
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lEADIHS^BlAMK^ZEiQ 18Z 



LIST 



LIST. OPTIONS 



LO 



If se1actsd# leading blanl^s In numeric 
fields are treated as zeros In arithmetic 
statements an-d conpar Isons. If not 
seltctedf nusieric fields ttsat contain 
blan1<s are in err®r« 



Single option parameter, 
option Is not selected* 



OefaultJ the 



LBZ = OH selects the option* 
Listing file. 

This parameter specifies the file where 
the product writes the source listing^ 

dl agnostics* statistics* and any 
additional list Infori^satlon Csee 10 

par aaeter I • 

Single specified value parameter* 

default "SLIST. 

Listing options. 

The options of this pararaeter specify 
Mhat extra Inforwatlon will appear on the 
listing file {LIST parafneter). Multiple 
options pay be specified* The defined 
options ares 



k 



Attributes. A listing of the 
attributes of each entity defined 
within the program is produced. If 
R Mas selected* the references are 
shown on the same listing. See 
section 3.3.5 for more information 
on attributes. 



Prohibit Banner. The banner 
sent to the Listing file. 



is not 



BD 



DE 



Byte Offset. (Release 2 feature) 
If source statements are I Isted* an 
offset field Is included {see 
section 3.3.3.3). This option is 
»iieanlngful only for wide forsiat 
1 1 s 1 1 n g s . 

DETAILED EXCEPTIONS. Print out 
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exception file messages as often as 
a record is sent to the exception 
flte, 

PI. MBPm k storage layout laap for 

coiupon blocks and equivalence groups 

ns Merge Statistics* Turn on listing 
of fierge statistics* 

Object code listing. A listing of 
the generated object code with 
Instruction fineiionlcs. 

P Proliibit prouipt* The norroal input 
prompts are not sent to the Listing 
fl le. 

R Cross reference listing* A cross 
reference of program entitles 
showing locations of definition and 
use within the program. 

RA Cross reference listing of all 

prograiB entitles whether referenced 
or not* 

RS Record Statistics* List the 
statistics for the records 
sorted/ierged* 

S Source* Source listing of the 
progr aw* 

SA Source listing of all source 

statements including lines turned 
off by a source embedded NOLIST 
directive* (See section 2.4*2) 

SO Source original* Provides a listing 
of the original source* For 
example* In COBOL* this listing Is 
produced before expansion of ••COPY" 
and ••REPLACE^' statements* 

f*^ultlpie option parameter* default * S* 

to » NONE causes none of the list options 
to be selected* 
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LITERAL.CHARACTER 



LC 



MACHINE _OePENDEMT 



m 



This parameter can be used to change ttie 
character that dslifnlts non-numeric 
literals. Default literal character Is 
quotat I on fflark, 

IC-*0FF Is an error* 

This parameter specifies whether use of 
nachlne dependent source features Is to 
be diagnosed and If sOf how severely* The 
severity level Is one of the folloMlngs 

I or Inf or «at lonal 

W or yarning 
F or fatal 

Errors of type •ERROR* hHI be treated ^s 
equivalent to • FATAL «♦ 

Single specified value parameter* 
Default = NONE> aiachlne dependenci 
not to be diagnosed* 



es are 



HASS. STORAGE. LIHIT 



ONE.TRIP.DO 



QPTIHIZATIQN 



HSLI1# Hass Storage 11 pit* This pararseter 
HSl specifies the naxIflBUiB number of 

characters that jpay reside Qn i^ass 
storage during execution of the product 
Cfor example* SORT). 

f^SLIM = expr* The number of characters 
Indicated fey tmpr is the siass storage 
limit* €xpr must be an Integer* 

OTD This parameter selects the mlnimuffl trip 
count for FORTRAN DO-ioops to be one 
rather than zero* 

OPT Optimization* 

This parameter specifies the level of 
object code optimization* All products 
need not support all defined levels* 
However If product supports a defined 
level* it must be selected by the 
specified option name* Ideally all 
products should recognize all defined 
options and issue Informative diagnostics 
for unsupported options that the user 
selects. AlloHable options are J 
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DEBUG Object code Is stylized to 

facilitate debugging* Stylized 
code contains a separate packet 
of Instruct Ions for each 
executable source statement* 
carries no variable values 
across statement boundaries In 
registers* notifies DEBUG eacfi 
tlf!!e a beginning of statement or 
procedure Is reached* etc* 

toy Lowest level of production 
qyality code. Code is not 
coffipletely stylized. 

HIGH High level of production quality 
code* 

SInqla specified value paraineterj 
default = DEBUG 

QWNCODE^FILE OHHF Owncode file. For products Mhlch provide 

the capability to specify user generated 
owncode procedures. This parameter 
specifies the source of owncode 
procedures. See parameter OWNn. 

oyHF * file-name. File flle-naroe mIII be 
loaded. 

Default » omitted. 

QyNCODE^FlXEO. OWNFL* Owncods Fixed length. See also OWNn. 

LENGTH QFL This parameter specifies the record 

length In characters of all records that 
will be input to a product from any 
owncode procedure. See also OWNHRL 
parameter. 

GWNFL * <integer>. Every record supplied 
by an owncode procedure viill contain 
exactly <lnteger> characters. Default* 
(See OWMHRL). 

OyNCODE.HAXIHUM. OWNMRL Ownc ode.Hax i mum.Recor d.L ength. The 
RECQRO.LENGTH OMRL maximum length In characters of any 

record suppi led by any owncode procedure 
Is specified by this parameter. This 
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OyNCOOE.PRaCEDURE.n OWMn 



par abater may not ba specified If the 
prodyct has Input or output files and If 
any of their associated HRl's are at 
least as large as this HRL» See also 
oyHn* 

OWNHI^i * <lnteger>. There mIU be at 
iiost <lnteger> characters In any records 
supplied by an owncode procedure* 

Deftyits If oyNFL and OWNHRL are both 
oiltted# the record length specification 
will 6ep&n4 on the length specifications 
of the Input and output files* If all 
Input and output files have fixed-length 
records of the sape length that length 
wlil serve as the default for QWNFL* 
Otharwise the largest ML Qr FL frop any 
input or output file i^lll serve as the 
default for QyNHRL. 

a^ncode procedure n Cn « 1* Zs 3# 4# 5# 
• ••«}• The liaxiiiufli of n Is left to the 
Individual product* Qwncode procedures 
are user written routines that may be 
loaded with the product and executed at 
specified points during product 
eKacution. See other OWNCO0£ 
parameters for raore information on this 
capab I i ity* 

The procedure specified by this 
parameter will be executed at a 
specified point n during product 
execution* 

Q^Hn « proc^nape* The procedure 
proc_nan?e will be executed at a 
specified point n* 

Default? No procedure will be executed* 



RETAIH^ORGINAL. 
ORDER 



R€TAIN, 
RET 



Retain Orglnal Order* 

Equivalent records or records with 
equivalent identifying characteristics 
will be output in the same order as 
input by a product* For example* with 
SORT* the equivalent Identifying 
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RUNTIHE. CHECKS 



RC 



SEQUENCED. LINES 



SL 



RETAIN • ON. Recof<ls 


characteristics will r 


Of igi nal order. 


RETAIN « OFF. Records 


characteristics will n 


retain their original 


OefayltJ Sarue as RETA 


This parameter control 


checlfs are compiled in 


code and/or selected f 


library routines* Run 


product dependent but 


supports one of the on 


here* it must be selec 


specified. Defined va 



characteristics nould be equal keys* 
The order in which nultiple Input files 

are specified Is the order In which 
records with equivalent characteristics 
are retained with this paraiiieter* 



with equivalent 
eta In their 

with equivalent 
iot necessar I ly 
order « 
IN«OFF. 

s which runt I rue 
to the object 
or runtime 
time checks are 
if a product 
es described 
ted by the value 
lues are« 



R Range checks. This option selects 
range checking for one or ?aore of 
the following 

- character substring expressions 

- scalar subrange assignwents 

- case var i ables 

S Subscript checks. This option 
causes subscript and index 
references to be checked to ensure 
that they are within program 
defined litnlts. 

T Tag field checks. Selecting this 
option ensures that accesses to 
variant records are consistent 
With the value of their tag field 
(if one exists). 

This is a multiple value parameter. 
Default is all supported values 

se I ected. 

This parameter selects FORTRAN 
sequenced mode source line format as 
described In section 3.2 of the FTN180 
SRS. Note that this format Is 
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SOURCE 



STATEMENT. LENGTH 



STANDARDS. DIAGNOSTICS 



Incofflpatlbie with the standard SIS 
{section E.B.E) source line for»at 
which allovis the length and location 
a line nyiiber to be specified In the 
source file attributes. 



of 



Single option parameter. Default « QFFf 
source I Ines conform to the standard 
SIS format. 
SCU Input. 

Line iroages of the generated progra»5 
will be written to this f 11 e# in a 
foriiat acceptable as input to SCU* 
Etch prograia unit on the S file will be 
preceded by an SCU directive which 
Indicates the beginning of a new source 
deck. 



Single specified parameter valuer 
default = SNULL* 

SL Statement length. This parameter 
specifies the iHaxlisuis length of a 
source statement. The default Is to be 
specified by each product which 
recognizes this parameter. 



Standards diagnostics, 
applicable standard). 



(ANSI or other 



This parameter specifies whether use of 
non-standard Input source statements 
are to be diagnosed and If so> how 
severely. There are two values 
deflnedi sever lty> and name of 
standard. The severity is one of the 
f I I owi ngs 



Inf orjuational error, 
errors are treated as 
this severity* 



Standards 
errors with 



Standards errors result In warning 
messages. 

Fatal error. Non-standard usages 
result In a fatal error. 
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Errors of type 'ERROR* will be 
treated as e«iulvalent to *FATAL«» 
The second value* naie of standard* Is 
to be defined by tlie products as 
appropriate* If this parameter Is not 
specified* then non-standard extensions 
to the product are allowed* Cnot 
diagnosed as errors). 

STOsNOME causes standards errors not to 
be diagnosed. 

Multiple specified value parameter* 

default « NONE* 

STATUS ST Status Variable. 

This parameter specifies the nane of 
the set status variable to be set by 
the product to indicate the occurrence 
of error conditions* See sections 3»4 
and 4»^ for an account of the status 
variable. See also NOS/VE ERS. 

Single specified value paranietsr* 

trrnrs of type «ERPQR» will be treated 
as equivalent to •FATAL*. 

Default status variable name is 
STATUS. See Error Processing 
section 3.4 for a description of error 
processing that results from use of the 
default status variable. 

SUH Sum Fleld(s). 

This paran^eter specifies that units of 
input data having key fields equal (see 
KEY parameter) roay be combined Into 
items or units in a product dependent 

m a n n e r • 

(For example* SORT i#ill use the 
parajneter to combine all records* 
having Key fields equal* into a single 
record. Each sum field in the new 
record Is foriied by suinmlng the values 
in the corresponding fields of all 
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equal records*) 

syN«<valye-Mst> 

The value list will contain one or 
fflcre value sets* Units of Input 
data with equal key values will be 
combined Into new units or items 
and fields specified by the value 
sets will foe sujiroedj according to 
product specifications and needs* 

Multiple specified value pararpeter* 
default « NO Sm FIELDS* 

SUBPROGRAH SP If this option Is selectedf the program 

is compiled as a subprogram instead of 
as a main program* 

Default I the option Is not selected* 

SUBPROGRAM « ON selects the option. 
TAPE^SCRATCH^FIIES TAPES* Tape Scratcl? Files* 

T The tapes with the naies specified by 
this parameter will be used by the 
product to reduce the disk space used* 
The tapes must have already been 
requested prior to execution* The foras 
i s J 

TAPES « Cfile_na!i5e #f lie. name •**) 

Default! Tape scratch files will not 
be used* 

TERHIHATIOH.ERRQR. TEt This parameter specifies the mlnlffiuifl 
LEVEl diagnostic severity level which will 

cause a product to return an abnormal 
STATUS upon completion of processing* 
A normal status Is returned otherwise* 
The severity level is one of the 
fo I lowing! 

I or Infori^ational 

y or warning 

F or fatal 

C or catastrophic 

For 170 cofflpatlbl I I ty> products are 
free to use 'T' In addition to •I«* 
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HOMever* output will always use *!•# 
not *T', Errors of type 

t5e treated as equivalent 



•ERROR* will 
to « FATAL «• 



TEXT.NAHE 



Tf^ 



TO 



TEXT.R^SIDENCE 



TR 



Single specified ^alus parai^eter* 

default « F, 

Names of texts to be read froip the 
files or libraries specified by the 

TEXT.RESIDENCg paraffleter. The total 
nuieber of values allowed is product 
dependent* Products that have a text 
natte directive raay choose to support 
the TEXT.RESIOENCE but not the 
TEXT^HAHE parameter, A fatal error 
occurs if any of the texts specified Is 
not found* 

Multipls specified value parameter* 
default Is no text* 
New file. 

This paracReter specifies the data 
output file for the product* For 
exaiuples file to which a copy utility 
^r Ites* 

Single specified value parameter; 
default = NEW. 



Napes o 
I i br ar i 
sped fi 
by prod 
nuipber 

provide 

TEXTURE 
us ed. 
TEXT.RE 
for TEX 
TEXT.HA 
texts o 
first o 
TEXTURE 
us ed. 
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product 
that na 



f resi 
es) to 

ed by 
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dences 
be se 
the TE 
rec tl V 
ues al 
f no t 
first 
E name 
t name 
E i s 
OENCE 
ameter 
icate 
nd ( in 
E name 
ch nam 
E para 
look f 
not f 
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exampie is 



sx ample 2i 



TERHIHAL^TYPE 



IT 



library set will be searched for a 
Hbrary iiith that nane* If the nai»e Is 
not found* -Qs a file or library^ a 
fatal error will occyr* 

Huftlple specified valye parameter* 
Oefaylt value list is text name value 
I ist. 

If file Fl contains texts A# Ct and 
and library L2 contains texts 8 and C 
and file F3 contains texts E and A then 

TN»(A>8fC^D#E) and TR«CFl* t2#F3) 
Mill result In selecting texts as 
f 1 lows t 

Af Cp and frop file Fl 

8 from I ibrary 12 

£ ffowi flJe F3 

In the above ex amp I e* if in addition to 
a library L2> the user has a local file 
nawed L2 containing texts 8 and €# then 

TN»IA#BfC#D,E) and TR»(F1# 12# F3) 
Hill result in selecting texts as 

f I lOMS 

Af Cf and D f row file Fl 
8 and E fronn file 12 
nothing from library 12 
nothing from file F3 

Terminal Type* 

TT«COR 

Correspondence Selectric API 
terminal. 

TT=APL 

This type Is appropriate when the 
communications systern translates 
APL tern»inal codes into a standard 
intermediate code* 

TT«ASCII 

For full ASCII terminals not 
equipped to print the APL 
character set* Also used for 
non-API correspondence terminals* 



TT^yCA 
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For fyli ASCII terminals. This 
avoids frequent use of the shift 
key for letters* 

TT=aATCH 

For devices that support th« ASCII 
64-character set* Usually ase^i 
for batch or remote batch ASCII 
printers. 

Single specified yalue parameters* 

Default Is API for a time-sharing JobJ 
and BATCH for a batch or reiBOte batch 
joh* 
VERIFY. MERGE« VERIFY, Verify nsarge input order* Selection of 
INPOT.OROER VER this option causes verification that 

Input records to be iserged are In 
correct order* The form Is? 

VERIFY « ON* Verify for correct order* 
VERIFY « OFF. Do not verify for 
correct order* 

Default: VERIFY • OFF. 

WORKSPACi yS Initial Workspace specification* 

This paraineter specifies the workspace 
to be activated when the product Is 
called* The parameter is specified 
Nith values consisting of the following 
parameters defined in the NOS/VE ERS? 

file 

This section deals '*4lth the standard for the processing of 
source Input files by product set members* In this 
context* a file can refer to data originating from an 
Interactive terminal as well as conventional storage 
devices* This standard addresses the areas of source file 
organi zat i onf statement format* blank compression* and 
response to an empty Input file situation* 
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2.3.1 SOURCE imm FILE ORGANIZATION 



2. 3.1 SQURCe INPUT FILE QRGANIZATIOH 



Source Inpyt to CYBER 180 prodyct set members mmy be 
deslgnatad by the I directive on ttie control statement. 
If the I dir active Is otiiitted# the source Input defaults 
to the standard input file (batch mode) or terminal 
(Interactive iode). The source Input has a sequential 
structure* Bn<l Is accessed by means of standard Record 
Hanager Interfaces. 

Positioning of the source Input at open tinse Is 
constrained bf the r equl renant to allow different product 
set i^emfeers within the sarrse job (e.g. different coinpllersl 
to access the same file for their input. Therefore* the 
source Input Is m&ned with no-rewInd unless the rewind 
parameter Is specified on the control statement (see 
Keywords and Paraietar Descriptions In section 2.2). 

2.3.2 SOURCE STATEMENT F^O^HAT 



Each record In the source Input contains one to three 

parcels of data: 

. statenent Identifier <optlonal)| 

. line number (optional); 

. statement body. 

Products should he able to handle the optional statejnent 
Identifier and line nufpber. 

The source Input statement may take the following fonss* 
where 

b represents the statei^ent body* 

I represents the line number* 

s represents the staterPent Identifier* 

and brackets specify the optional portions of the forms 

b I s 

s I h 
s b I 
I b s 
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2*B.2«1 Statement lientlflsr 



2 •3.2,1 itMtmmt^M^tltltL 



Input soyfcs racords way contain optional statement 
identifiers such as SCU identifiers. If present* tf^ey 
occypy either ttie first or last 'n* characters* where *n» 
has a fflaxlfiutu valye of 18* If the statement identifier 
occiiples the last character positions of a record* all 
records must foe the s aiiie length. The location and length 
of the identifier are f I I e attr I butesi they are made 
ayallable via an operating systei^ request* 

This feature Is to allow files created by source code 
ytlljties to foe used as source Input. 



2. 3. a. a Lict-Muifefics 



Line numbers are numeric entities used by coinpllers and 
editors. In general* editors will affix line nursbers ^ 
lines and compilers will use these line nuflibers 
diagnostics* cross reference paps* run time 
messages^ etc.i line numbers should not be vwm.^^^v, »,. 
statement Identifiers that are produced by SCu and are 
alphanuwer Ic. 



to 
for 
error 
confused Nith 



The location of the line number In a text line may be 
Immediately to the left or the right of the text of the 
line. The position of the line number field Is conveyed 
via the file attributes. The line number field may be 
from o ne to six characters In size. The only valid 
characters In the field are blanks and the decimal digits 
to 9. Leading blanks are ignored. A line number Is 
terminated by antS of field or one or more blank characters. 

Additional semantics for the line number field will vary 
froip processor to processor. In particular* many 
compilers may not accept more than six digits. Another 
example Is the cross reference map produced by CCH which 
only has space for a six digit line number. Host 
processors will! also Insist that the line numbers be 
unique* ascending* and that every line be numbered* 
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The feody of eacli source input record is that part which 
represents the data to be scanned or processed by a 
product set meiber. It begins In position 1 If there are 
no statement Identifiers^ or if the identifiers appear at 
the ^r\^ of the record. Otherwise* It begins in position 
(n+1) where »n« Is the length of the statement Identifier* 

The nsaxifflujn size of the statement body Is product set 
member dependent and conforms to the size specified for 
the associated langyage. Source records shorter than the 
waxlfiyp are scanned to the %t\^ of the record. Records 
exceeding the inaxlRium size are truncated Cl«e» data Is 
transferred up to the fpaxifnyiijj a diagnostic is returned 
by the Record Manager* 



2.3,2*4 aia.cii.Q.§iii:as£iaa. 



The CYBER ISO Record Manager is responsible for 
cosapressi on/expansion of blanks* The capability to read 
the source Input in coippressed foriri is not provided* If 
the require^uent for this capability en?erges (for 
performance optimization)* It will be addressed In a 
revision to the standard. 



2.3.3.5 Eaiet^.iflEut-Eiie 



Diagnosis of an eiripty Input file results In the Issuance 
of a standard log uiessagai EHPTY SOURCE INPUT FIIE 
(forn?atted In accordance with conventions stated In 
section 3.2). If the job involved is interactive In 
origin* the ?!!essage Is also sent tc the terminal {see 
section 3*2.1.2.). In addition* generation of the primary 
output of the Product set member involved (e.g, file 
specified by 8 parameter for compilers) Is suppressed and 
the SCI STATUS variable (refer to section 2.2.4*2)* Is set 
to reflect the error. 



2.3.2.6 i^uii.iau££a-Liaa-C2Qi£aai;ifiQ 



The number of records In the source file should be the 
same as the nuiiber of source lines In the source list* 
Even though a null record has no data* the record should 
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2«3«2»6 Null Source Line Convention 



not be tgnorad* Sloce^ In tlis source list* tfie absence of 
all characters in a record looks the same as a record 
containing all blanks> nyil records should be inappecJ to 



all bl anks* 

2.3.3 DISPOSITION OF INPUT FILE 



The final action to be taken with respect to the source 
Input file Is dependant on the manner of terfsi nation of 
the product sat mefnfoer. For normal terial nation^ the Input 
file is closed with the no-rewInd option! this Includes 
the case where an ewpty file Is detected. For abnormal 
terfiinati on* the product set jsereber is responsible for 
positioning the input file as if norsial processing had 
occurred^ usiiig appropriate facilities of the Record 
flanager ♦ 



2 * 4 aQll£iLAIil3M.I2IE££II¥S S 



The user of a Coraplter may control various activities of 
the cojupller by specifying one or more consplle time 
directives. The directives are expressed either in a 
special form of a comment within a particular language 
{e.g. FORTRANf COBOL) or In special source statements If 
the language provides such stateicents <e.g. CYBIi). 
Compilers that already have special source staten^ents for 
directives do not have to process directives embedded 
Inside comraents. Coipllars which now have compilation 
directives In comments should honor both old and new 
directives. MHen a compiiation directive conflicts with a 
control statepant parameter option* the compilation 
directive overrides For example* the options for the 
parameter tO will be overridden by a conflicting directive 
unless specifically stated otherwise* such as 10«SA. 
However control statement parameters denoting file status 
or destination would take precendence over directives. 
For example LIST=$null would take precedence over any 
directives requesting that something be listed. 

Since the major programming languages are subject to 
standardization by bodies such as ANSI* FIPS* and ISO* 
Initial compliance with the form of compilation directives 
in this section may have to be altered In the event of 
standards covering this area. Because of the long term 
posslbllty that the major languages will be different* 
full uniformity across 180 products Is unlikely. 
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2.4 COMPILATION DIRECTIVES 



Therefore* products with CYBER ITO directives that do not 
cofjforw to the syntax contained here should retain 
Gompatjblilty nith the CYBER 170 form to minlfaize 
lilgration problems rather than cause a conversion In going 
to 180 and possibly have to cause a second conversion to 
coiply Mith external standards* Hew directives In areas 
which Mill never be syhject to standardization should 
follow the for^ of this section. 

The Conpllers support t*io general classes of dlrectlvesi 

« C offlp I I er Call directives 

• Source Einbadded directives 

As discussed }n section 2.2* the directives specified on 
the command calling the cosupiler are established for the 
entire compilation process. They apply to all subsequent 

coiBPllatlon units Cpro^rajri nodules or subroutines) i^lthln 

the compile process. 

Source eiihedded directives are established only for the 
compilation unit In which they BppB2.rm They are expressed 
either in a special form of a consient within a particular 
language (e.g. FORTRAMf COBOL) or in special source 
statements if the language provides such statements (e.g. 
CY8IL). Co»npllers that already have special source 
statements for directives do not have to process 
directives embedded Inside compents. The syntax of a 
coaipiler directive within a coiunent Is as followst 

$ directive I ^directive 3 . • . 

Example - FORTRAN source embedded directives 
C$ directive - C In column 1 

Example - COBOL source embedded directives 
*$ directive - ♦ i n column 7 

Multiple directives may be contained on the saif?e Input 
statement. 

Where directives have parameters* they follow SCL rules. 

Source embedded directive format errors are diagnosed with 
warning or fatal class error messages* as appropriate* 

The following standard applies to compilers that process 
directives embedded Inside comments* A compiler Is not 
required to Implement all the features listed below* nor 
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2.^ caiiPiiATiQ« directive: 



is tlia Mst restrictl¥a« 



2«4«1 PAGE EJECT 



EJECT 



Tt^is dlrectlire causes the page line countsr to be reset 
to 1. Mhen the line counter is reset to 1# a standard 
listing header will be written on the source listing prior 
to the neKt source line. This directive will be listed 
before the page line counter Is reset to !• If the page 
is at top-of-form when this directive is processed^ it is 
processed as a '*no-op"« If a continuous page is being 
written^ this directive Mi[\ simply result in a triple 
space without a new listing header* 



2,4,2 SOURCE ilSTIHG 



LIST and NOLIST 



The NOLIST directive causes the listing of the source 
wodulsf Incuding cojupller directives* to be suppressed at 
this point. The LIST directive causes the listing of the 
source jnodule to resume at this point. The directives 
LIST or NOLIST are listed at the point they occur. 



2.4,3 LINE SKIP 



SPACE = number 

This directive causes the specified nuinber of print lines 
to be skipped at the point in the source module listing 
that It is processed. This directive will be listed 
before the skip action starts. If the page line counter 
Is exhausted before the specified nuwber of lines have 
been skipped* the JIne counter is reset to 1 and skipping 
terminates, 

number i Integer value 1 thru nj If omitted 

(Including the ♦•«♦«), the default Is !• 
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2*4«3,1 LINE SPACING 



2*4.3.1 LiM-i£4CiM£ 



SPACING « number 

This directive specifies tfie nymber of lines to be 
advanced before each source line is listed* The neu value 
for spacing win take effect with the next line following 
the spacing directive. Wtien listing a source line if the 
page line counter is exhausted before the specified nusiber 
of lines have been sklppedf the line counter Is reset to 1 
and skipping ter iilnates. 

nufpbers Integer value 1 thru 3 indicating s ingles 
double or triple spacing; If oral t ted 
{Including the *»x*»)* the default Is *»1*'. 



2.4.4 TITLE LINES 



TITLE » character string 
SUBTITLE = character string 

These directives define strings of alphanumeric characters 
in SCL foriitt which will be printed following the standard 
page headers on the source module listing (see TITLE Lines 
In section 3J. TITLE causes a page eject to occur* unless 
the page is already at top-of-f om. TITLE is listed at 
the top of the new page. 

SUBTITLE also causes a page eject to occur* unless the 
page Is already at top-of~form or TITLE has just been 
processed. SUBTITLE Is listed at the at the top of the 
page following TITLE If there is one. 

Compilation Directives 



2.4.5 R^NGE CHECK 



RANGE and NORAMGE 

The RANGE directive directs the cotr^piler to generate 
additional object coda which performs range checking for 
subscripts^ Indexes* scalar assi gniients* case variables* 
etc. 

The NQRANGH directive directs the compiler to not generate 
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2*4.5 RANGE CH€CK 

additional range checking object code. 

The default for tfie cofifsllatlon unit is NORANSE* 

2.4.6 EXECUTION TRACE 

TRACE and NOTRACE 

Tlie TRACE directive directs the compiler to generate 
additlonai object code which facilitates tracing the flow 
of the program during execution. The TRACE directive is 
ignored unless the DEiUG-TR parameter Is given In the 
product call coi^iniand. 

The NOTRACE directive directs the compiler to not generate 
additional flo^ tracing object code. 

Hinlatuffl trace infornatlon will always be provided* See 

section 5.4.1.2. 

The default for the cofflpllation unit Is MOTRACE* 

2.4.7 OEBUS STATEHEHTS 

DEBUG and NODEBUG 

Source Input statements that are to be cofupiled only for 
debugging purposes ^re enclosed between DEBUG and N00E8UG 
directives. Enclosed source stateisents are compiled only 
if the OEBUG«DS Is given in the product call cofflwand. 

2.4.8 SEQUENCE CHECK 

SEQUENCE and MOSEQUENCE 

The SEQUENCE directive directs the compiler to check the 
Input source state^ient sequence numbers for ascending 
order. 

If a secjyence error occurs^ it will be flagged with a 
warning diagnostic. (See section 2.2.4*2} 

The NQSEQUENCE directive directs the compiler to Ignore 
Input source statement sequence numbers. 
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2»%,S SEQUENCE CHECK 



Tti8 default for the con5pnatiO(^ unit is NOSEQUENCE. 

The SEQUEHCE and MQSEWer^CE lines themselves are not 
checked for sequence. 



Z*h*9 OBJECT CODE LISTING 



OajtlST and N00841IST 

The 03JLIST directive directs the compiler to print the 
object code listing at this point. The N008JIIST directs 
the coiipiler to stop printing the object ilstlng at this 
point. The object code yili appear in the object code 
part of the listing (see section 3.3.4). 

QBJLIST and NOOBJLIST act Independently of LIST and 
NQLIST. The default for the coffipliation unit is NOOBJLIST 



2.4.10 STACKING CQHPILATTON DIRECTIVES 



PUSH (compilation directive) and POP 

The PUSH command nil I place the specified compilation 
directive on the top of the •'directive stack**. The POP 
directive will remove the top directive from that stack. 
This procedure will allow teR?porary alteration of the 
local environment without permanently affecting the global 
envlronipent. For exejuolef If it Is desired that a called 
comi^on deck lists its name on the print file> regardless 
of whether the entire comjiion deck Is being listed^ then 
the following would be placed in the common decks 

PUSH (LIST) 

comment Including coniuion deck name. 

POP 



££QQyCI^aiE££IIii£S 



The format of product directives (commands) ?aust follow 
the set of language rules and conventions of the Systeju 
Coiflpand Language. These directives frequently occur in 
products (often various types of utilities) that are not 
compilers and are thus listed separately* The standard 
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2.5 PRODUCT DIRECTIVES 



PBT Bmtter n§n?es as describe^ 
must be used as applicable* 



In sections 2«2«4,2 and 2#5«1 



2,5.1 STANDARD PARAMETERS 



These parameters occur frequently enou9N to warrant waking 
sure that all commands using the^ do so In tfie sar^e i*ay. 



P ar ameter 
Ntie 

BRIEF 



FULL 



COUNT 



FILE 



WAIT 



NOWAIT 



USER 



A 1 1 as 

8R 



FU 



cou 



WAX 



NOW 



US 



Parameter Description 



of 



This parameter specifies that a brief fori 
Information is requested for display at a 
terminal or print file* It Is a boolean used 
In conjunction «ltb the full parameter* The 
brief selection Is used as the default* 

This parameter specifies that a full form of 
Information Is requested for display at a 
ter?!ilnal or print file. It Is a boolean used 
In conjunction with the brief parameter* 



This parameter 
files records) 
function* The 
This paranieter 
a file used as 
function. It 



specifies a count of units Ce*g« 
associated with the coiRfsand 
default value Is one * 
specifies the local file name of 
the object of a connnand 
Is used when the file Is not one 



of the specific files Identified 
2*2.4*2 Cs*g. COMPIlEf INPUT). 



In section 



This parameter specifies the requestor should 
be placed In a wait state if a request can't be 
Immediately processed (€*g* a file is busy). 
It Is a boolean used In conjunction with the 
nowalt parameter. 

This parameter specifies the requestor should 
not be placed in a wait state if a request 
cannot be Iwnnedi ately processed. It Is a 
boolean used In conjunction with the wait 
parameter. The nowalt selection Is used as the 
def au It* 

This parameter specifies a user 
Identification. It is always the 31~character 
user and family names as specified to gain 
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2.5.1 STANDARD PARAHETERS 



access to the systeiB. 

PASSWOf?0 PA This paraiiatar specifies a 31-character 

passi^ord needed to gain access to an entity or 
to execute a function, 

UPOH This paraieter specifies the local f I ie name of 

an output file. It is used wh^n tlie file is 
not one of the specific files identified in 
section 2.2.4.2 Ce.g. IIST# 8IHARY-08^£CT). 

LIBRARY LI This parariieter specifies the local file nawe of 

a library file Ce.g. source ilforary# object 
I I b f a r y I « 

a.5.2 STANDARD COMMANDS 



These commands are re<iylr8d# as a miniiaum^ If t^e functions 
described by the coraraands ^re Included in the utility. 
Utilities ?iay optionally Include aliases to the required 
ccnsn^and • 

Cofflipand Description 

QUIT This directive enables the user to exit# or get 
out of 9 a ut 1 1 i ty. 
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3.0 OUTPUT 



3.0 QyiEyi 



All products will fol lovi a uoifoni sat of conventions for 
generated outpyt* as specified herein. All CYBER 180 
products will ys3 ths facMities of the CYBER 180 Record 

Hanagsr for sucfi output* 



3.1 E£!:Q!2l!£MI^£J}-iyiSB£E.MS£S 



The use of hexadecimal nuHibers on output produced fey CY18G 
software aiyst be controlled to promote readability. All 
products will follow the set of guidelines set herelri. 



3.1.1 SITUATIONS AHD RECQH^ENDED NUHBER BASES 



Address* Address Offset^ 



Dayfile information? 

Object Code listings! 

Instruct i ons: 

Operand f le I ds5 

Branch Oest I nation? 



Instruction Offset? 
Core and File Dump: 



Hexideclttsal • When a length Is 
specified in conjunction *«ith an 
address or address offsetjf the 
length is represented In 
hex I dec I raal ♦ 

Dacifljai statistics* decimal 
resource I imi ts* 



Hexadecimal (A or 8 hex digits) 

Dec iinal 

Hex I decimal. The value Is the 
instruction offset of the 
destination Instruction rather 
than the relative offset froni 
the branch Instruction. 

Hex Ideci msl • 

Various formats should be 
available* Including 
hexadeci (nal * ascli* Integer* 
floating point. 
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3,:i*l SITUATIONS 



AND RECOHMEHOEO NUMBER BASES 



Pags numfeersJ 



Dec imal • 



3.2 toss 



Tha logs treatsd in this section are those maintained by 
tfie operating system. The OS provides interfaces to put 
ite^s into tNe logs and the SIS provides conventions on 
flow to use these Interfaces and on the contents of data 
put Into tf^e logs. 

Tfie set of logs Is divided Into t^o major classes* ASCII 
and binary. The ASCII logs contain only ASCII-encoded 
data. The binary logs may contain any type of data. 

The logs Includes 

- system log (ASCII) 

- job log (ASCII) 

" account log (binary) 

- engineering log (binary) 

- statistic log (binary) 

- job statistic log (binary) 



3.2.1 ASCII LOGS 



Each ASCII log contains a set of records ordered by time 
of entry into the log. Each record contains several 
fields* some automatically provided by the logging 
mechanism* and some provided by the caller of the 
mechanism. The following fields are proy/ide^ fcy the 
logging oiechanlsm: 

- tinie of day of the entry of the record Into the log 

- origin of the message (coffijisand* program-Issued* 
command from procedure* etc. — that Is J callers In 
OS rings may specify the message origin In the call* 
callers In users rings may not and their messages 
are alviays "pro gram- i ssued*') . 

The system log has an additional system-provided field to 
Identify the message Issuing job. Also* each log record 
contains a field for data provided by the program making 
the record entry. 
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3.2*1 ASCII LOGS 



Except for certain operating systeis programs* the 
interface to be used by the OS and product set for puttlni 
fiessages Into ASCII lags is that provided by the "isessage 
generator**^ a facility of tlie OS Csee NOS/VE ERS)« The 
message generator Is given a status record that describes 
the type of ii^essage and any variable data to be ••edited'* 
Into the fiiessa?ie« The message generator* 

- finds the appropriate message sl^eleton In a library 
which Is In the current job library list 

- edits the variable data Into the inessage 

- logs the final rnessage in whichever logis) are 
specified by a combination of! 

* destination specified within the f«essags 

skeleton record 

* Job option selection Ce«g«# "log only errors*** 
•*log all fatal s"# etc.) — things such as 
message Importance level are defined In the 
message generator call, 

" displays the iiessage at a ter?i?lnai depending upon 
job option 

The use of a message generator eases? 

- consistency of messages within and across products 

- physical coipresslon of message text 

- extraction of message types for documentation 

- routing/suppression of messages based upon message 
levels {a,g#> trivial* fatal* etc.) and upon user 
desire for only certain levels {"level** or 
•'importance*' is specified in the message generator 
call* not In the Jijessage skeleton) 

- installation control over what kind of messages 
should appear In the system log 

Arbitrary user-Initiated logging need not use the message 
generator. 
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3.2.1.1 System? log 



3.2.1.1 SiS-tti-ki^a 



In addition to the basic systew-provlded flelds# each 
systes? log entry contains a field identifying the 
particular Job from which the lisssage cafse or to which it 
appi i es. 



3.2.1.1*1 PURPOSE 



The priroar^ purpose of the system log Is to serve as a 
repository for infor nation regarding external system 
workload. That Ist the Mork the systen was asked to do 
via copmands and the high level responses of the system In 
regard to tha commands. 



3. 2. 1.1. a CONVENTIQHS 



The systaii? log contains predosilnantl y a subset of Job log 
messages that are of Interest to the Installation* This 
normally Includes at leasts 

- all sYsteis level commands (supplied by OS) 

- all CGfj?mtnd cosipletlon loessages 

- start of each job execution (supplied by OS) 

- end of each job execution (supplied by OS) 

- rerun of each job execution (supplied by OS) 

- system Identification (supplied by OS) 

- other information supplied by the OS like date* 
hardware and software configurations and changes* 

deadstarts* recoveries* etc. 

The system log should contain only Indications of the 
n^ajor changes In state of the system and of individual 
Jobs. 

The specific messages that should be routed to the system 

log in the default "as-shipped" system will be determined 

on a case-by-case basis using these general conventions as 
gy I de I ines. 

Note that since message destination (which log(s)) 
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3,2.1,1«2 CONVENTIONS 



Instryctlons are separate fron the ?pessage-l ssul f?g code* 
this detemlnat i on does not Involve code mod if Jc at Ion • 

Sea Job Log* Conventions for further guidelines* 



3 •2.1. 2 ial^..La^ 



3.2.1.2.1 PURPOSE 



The purpose of the Jofe log Is to hold a trace of Joh 
execution. Information concerning the work requested and 
accomplished Is recorded here. It pf^^\4^% a susBiaary of 
the floii of the Job# problems encountered and charges 
accrued by the Job. 



3.2.1.2.2 CONVEHTIOr^S 



Keep log messages siiipla and short. Use the logs for 
suiPfiary Information. Use list flies or binary logs for 
detailed or repetitive data* 

Messages longer than the ii stable output "narrow" format 

are discouraged. 

Simple completion massages that convey no more information 
than "it's done*' are not to be put into logs. In a batch 
case* completion Is obvious frofs the appearance of the 
next command. In ^x\ Interactive case* the OS will see to 
It that the ter?5«inal user is notified of corupletlon. 

Completion messages that convey a sirsall asisount of useful 
or Interesting Inforfnation are encouraged In order to 
enhance the "live" appearance of the system. For exaj^pie^ 
"23 records sorted." or "Cycle 25 used.". Information not 
specific to the operation performed should not be 
included/ however (like CPU tiwe for a compilation). 

Messages Cat least the non-brief mode ones) should have 
the general apoearance of nornjal sentences. That ls# they 
start with a capital letter^ are comprised of both upper 
and lower case letters* and end with a period. When an 
"extended message" of more than one line must be Issued* 
each line should not* however* end with a period* but each 
sentence should. This familiar sentence-type structure 
adds to the "comfortable" feeling that we'd like our users 
to have for our systee?. 
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3.2,1.2*2 CONVENTIONS 



Accounting and loi#~level statistical and hardware error 
Inforisatlon Is not to be placed Into ASCII logs except by 

the OS. 

Hessage-at-t-t Ime "current status" messages CI Ike 
♦»co!npliin<i aiptia... coippHIng feeta...") are not to be 
placed In logs. The OS »illl provide a ipeans for programs 
to post ttiese kinds of messages. The current message will 
be displayed at an Interactive teriilnal when re<iuested by 
the teriilnal users. Posting of these i^sessages Is 
encouraged. 

The message generator mIH supply product and message type 
Identification based upon the status record passed to It 
in a call. Products should not include this Information 

in messages. 

yhen wore than one datum is to be logged* try to ?iln$mlze 
the nuiber of lessages lines produced by putting more than 
one datura on a line. For exaisple* issue: 

23 records sorted; Herge order 12 used; 14 Insertions. 

rather than; 

23 records sorted. 
Herge order' 12 used. 
14 Insertions. 



3.2.2 eiMARY LOGS 



Binary logs are provided in order to allow the recording 
of log Information In a compact form that Is readable 
prT^arlly by programs. Each binary log contains CY8IL 
records ordered by time of entry into the log. Each 
record contains several fields* so»e automatically 
provided by tha logging mechanlsRi* and some provided by 
the caller of the mechanism. The following fields are 
provided by the logging mechanism? 

- time of iay of the entry of the record into the log 

"- the Identification of the job from which the record 
came or to ?«rhlch it applies (this field Is not 
recorded In the Job statistic log) 

- the origin of the record (system or non-systera — 
indicates only **hether the caller is Inside or 
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3.2.2 8INARY LOG! 



outside systen rings* not which product or which 
syste?!! agency —this latter information is given by 
the ♦•indicator of the type of recorcl»* fleid*) 

Fields provided by the caller Inclyde* 

-- indicator of the type of record {e«g«f number of FTN 
source statewentsf SRJs at end of jobf etc. — the 
Indicator codes mIII be assigned and wanaged In a 

manner s iffl 1 1 ar to that used for status condition 
codas as described in section 3.4) 

- variable data depending upon the record type 

Except for certain operating system programs* the 
Interface to be used by the QS and product set for putting 
records Into binary logs Is that provided by the 
"statistics facility" of the OS. The statistics facility 
Is given a data record that describes the type of record 
and any variable Information associated with the record. 
The statistics facility finds infoniatlon about the given 
record type in a "table**. This "table** directs the 
statistics facility to do some combination of the 
f ol I oMing thi ngs s 

- add the variable ItenCsl to counter Cs) 



- log accumulated counter values to a specified binary 
log or set of binary logs ^hen a threshold counter 
value Is reached or when a certain tifne has elapsed 
since the last "put** to the logCs) of the 
appropriate counterCs). The set of logs Is 
specified In the •» table**. 

- simply log this record In the "tabl e-specl f i ed** 
log(s) 

The use of the statistics facility for binary logging 
eases s 

- installation tailoring of what Is considered to be 
accoyntlngjj performance* etc* data. For example* 
site A ffiay consider CPU tlipe to be accounting data* 
while site B considers it a workload statistic and 
considers '•number of statements compiled** to be 
accounting data 

- optional routing of statistics to the Job statistic 
log {based upon user desire* but constrained by 
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3.2,2 BINARY LOGS 



Instal lat lor^ willingness — via ••table" 

inf of^tt i on — to divulge certain information) 

Since the statistics facility determines ttie log Into 
Mhlcti a given statistic (for exa^plet PIOFR data) Is to be 
placed (based upon an Installation and CDC defined tible)# 
systeis and product I fflpleiuentors stiould not be concerned 
viitti Mhjch log(s) are used for "their" statistics* This 
napping mIII be deter fPlned iater« 



3*2.2«1 4££aiiBt-La£ 



3.2.2«1.1 PURPOSE 

The purpose of the account log Is to hold accounting and 
billing Information. This consists of resources and/or 
services used* »*who" usBd them and "who" to charge* The 
account log should be the only log needed for an 
installation to do billing. 



3.2.2.2 £naia££LiQ£-Laa 



3.2.2.2.1 PURPOSE 

The purpose of the engineering log Is to hold Information 
regarding systen^ hardware usage and errors. The 
engineering log should be the only log needed to perforii 
hardware usage and error an I ays Is. 



3.2.2.3 ^titisti£-Ua 

3.2.2.3.1 PURPOSE 

The purpose of the statistic log Is to holdJ 

- detailed system workload information 

~ detailed system performance Information (l.e.# the 
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3»2.2,3.1 PURPOSE 



Na^ the systei responded to the workload) 

klthQ\igh saie of thjs Information Is recorded in other 
logs^ a separate log Is maintained In order toJ 

- keep other logs relatively **clean*» or oriented to 
their own purposes 

- allow possibly large amounts of data to be recarf^Bd 
in a cowoact binary forn 



3. 2 « 2.4 iiafe-aialistiii-Laa 



3.2.a.4,l PURPOSE 



The purpose of the Job statistic log Is similar to that of 
the (global) statistic log* The global statistic log 
contains inf oriuat I on regarding all Jobs in the systewt but 
?i8y be read only by privileged programs / users* 
Individual users* howeverf may wish to see Information 
that Is available about thair own Jobs. The job statistic 
log laay be read by normal programs / users and contains 
Infomsation regarding a single Job^ similar to the "scope** 
of the ASCII Job log. 



3.2.2.5 aiQaLi-Lfia-iflaiaalis^Qs 



Avoid the use of character data. Since each record type 
Is pre-def|y^ed by a CYBiL record type definition* there Is 
seldom a need to describe the various data fields with 
keywords or the like. 

Message type naming follows the naming conventions 

described In SIS section 3*4. 

Use the binary logging facilities for PIDFR data. 

See the OS ERS and the SIS Usage Statistics section for 
minimum list of Items to be logged. 

Additional conventions will be added as design proceeds. 
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3.0 OUTPUT 

3.3 IISTABIE OUTPUT 



3.3 LliIifiL£.Qyi£UI 

Mh.en a significant aii^ount of inforiiatlon is to be returned 
to the ysar# it Is written to a "listable output file**. 
The standard forsiat of such a file is described here* 

CYBER 180 Output Standard Is defined In terms ofJ 

« Output File Organization 

• Listing f*age layouts 

« Page Header' Format 

♦ For?iat of Each Listing Type 

« Object Code and Debug Code 
3.3.1 LISTING PAGE FQRH4TS 



In the sections that follow^ the contents and format of 
the standard listings produced by CY8ER 180 Products are 
defined in ter^s of a vertical and horizontal layout* 



3.3,1.1 y.Q,LtlQMl^LMimkt 



Vertical layout Is defined In terms of the first printable 
line of a form following top-of-foroi positioning by the 
printing devlca. This position Is defined as line 1 of a 
foru? and is reserved for the first print line of the 
standard listing header. The product is not responsible 
for the physical alignment of line 1 relative to the 
perforated fold on fan-fold printer forfns. This is the 
responsibility of the user on printers with vertical 
positioning carriage tape mechanisms or the responsibility 
of the CYBER 180 OS Device Software on printers without 
vertical carriage mechanisms. 

yhen the last printable line of a form has been wrlttent 
the product will reset the page line counter to 1. When 
the page line counter is equal to 1# the next print line 
written Is preceded by a standard listing header with a 
top-of-form code in the first character position of the 
header print record. The product Is not responsible for 
the physical alignient of the last printable line relative 
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3*0 OUTPUT 

3«3.1«1 Vertical Layout 



to the perforated fold on far?:-fold printer forms* 



3.3*i,2 ffiEiai-iticikutss 



Eacli product roust obtain tlie output file attributes fron 
the operating system at the tiflie tha file is opened* 
These attributes Include print mode* page widths connect 
status# page formats and page length. Vertical and 
horizontal print density have operating system defined 
defaults which may be changed toy the user. 
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A continuous forra file is detected by checking the file's 
attribute page format* Connected files will default to 
continuous fori mode# but users may override this by 
specifying a page length for the connected file* 



3.3.1*2.1 CGMTIHUOUS OUTPUT FILE 

When forrBatting listable output for a continuous form> the 
product uses a standard triple-space code In the first 
character position of the line 1 output record (usually 
the first line of the header) to achieve top-of-forra 
positioning. Products will reformat listings for terminal 
users when required by this standard. 

Each type of listing (source listing* attribute llstlngy 
etc.) is preceded by a triple-space and the usual header 
nne(s)# but there Is not pagination as such. 
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3*0 OUTPOT 

3,3,1»2.1 CONTINUOUS OUTPUT FIL£ 



3..3«1,2*2 PAGINATED OUTPUT FILES 
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3 . 3, 1 • 3 it jada£i-Ca££iaaa-CLfiQtLSi-^aii£s 



Carriage control characters that are used should be 
restricted to the following set* 

Character Action 

blank Space vertically one line then print* 

Space vertically two lines then print. 

- Space vertically three lines then print* 

1 Eject to the first line of the next page 
before printing* 

+ No advance before printing? allows 
overprint Ing* 

This set represents the full extent of compatibility 
between current CDC usage and the proposed ANSI standard* 

Under NOS 180> horizontal print density and 

vertical print density are file attributes that the user 

i!?ay modify* The NDS* NOS/BH carriage control codes S and 
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3.0 QUTpyi 

3«3*1.3 Standard Carriage Cor^tr©} Codes 



T win r^ot be used to set or clear the 8 lines per Inch 

mode. 

It Mill be nactssary to make soise provision for selection 
of print density when HOS 180 print files are to be 
printed by NQS or NQS/8£» The first release of NOS 180 
Mill 6%p^n4 entirely on 170 state for print flies. 



3»3,i«4 fiailitatsi-La^aiit 
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Character position 1 of an output record is Interpreted by 
the output device software as vertical positioning control 
and is never printed (displayed) « Character positions 2 
thru 133 of an output record contain printed (displayed) 
characters. Colufun 1 of an output line is character 
position 2 of the output record* 



3 . 3 . 1 • 5 St Joil^i:il-.Lisliaa-.!iaasi£L 



All CYBER 180 Products will use a standard 2 line page 
header format on all listings produced by the products* 

Through this section* date and time fields conform to 
standards defined In section 4»1« 
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3.0 oyTpyj 

3*3. 1.6 OTHit F0RH4TS 



3.3.1.6 QItl£E.£QEaAIS 



If the line width specified Is other than 72* 80, or 132# 
the haading wMI foe mappad to one of the three standard 
listing headers. Other output *^ i I I honor the actual line 
width* unless specifically colufun oriented throughout the 
line Cas opposed to colutsn oriented for the first portion 
and open ended for the last portion* such as sourcel* 



line I of the cofP?ion page header contains the following 
fields (field definitions are in COBOL format)! 



Systein Han?e xC8) 

Product Nairn xC8) 

Product Version 9.99 



Product Level 



2ZZZ9 



Inst a I I Date 



99999 



Listing Name 



x{14) 



Operating System name* 

The longhand forp of the 
product nasie* i.e#* FORTRAN^ 
FHU* SASICf etc. 

Product version nunber* The 
nuffli^er after the dscliiai 
point Is shoi^n left 
Justified* i.e. 5.1* not 
5*01. This nufsber Is updated 
at the product source code 
level by the responsible 
developfuent organization for 
each new version release. 

Product PSR modification 
level contained within the 
product itself. This nuipber 
is updated by the build 
procedures for each new 
update release. 

Ordinal Date* In YYDDO 
forjnat* when product was 
added to the library* The 
date Is obtained frofi the 
CYBSR 180 OS using a standard 
Program Management request. 

Name of the particular 
listing being produced. The 
acceptable listing names are 
defined In the follov«lng 
sections which define the 
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3.0 aUTPUT 

3.3,1.6 OTHER FQRHATS 



fomat of each iisting type* 



Hodyie Na!«e 



X C31) 



Date 



x{18) 



Time! 



x{12) 



Page Nymber •PAGE* Z2z9 
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Date at the time the first 
header was written {listing 
Page Huiaber reset to I). The 
date is obtained froii the 
CY8ER 180 OS using a standard 
Program Management request* 
The date format will conforss 
to the standard given in 
section 4.1, 

Time of day at the tln^e the 
first header was written 
(listing Page Number reset 
to 1). The tliue Is obtained 
from the CY8ER 180 OS using a 
standard Program Manageiaent 
request. The time format 
will conforjp to the standard 
given in section 4*1. 

Integer number generated by 
the product starting at 1 and 
incremented by 1 for each 
page header written for a 
compilation unit. The page 
number Is reset for the first 
page header written for a 
compilation unit« This field 
is o?!?itted from the standard 
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3.0 OUTPUT 

3.3.1.6 OTHER FQRMAT* 



header mhen a continuoys forr* 
Is specified. The two parts 
are always separated by one 
blank. 



3*3.2 FORMATS 



Ttiree logical line width listing formats are generated by 
prodycts? 

- Page Fornatted lines of 132 characters 

80 Colu?pn Formatted Lines of 80 characters 

Narrow Formatted Mnes of 72 cliaracters 



A standard healer will be written at the top-of-forffi 
position of a listing ^heneyer the page line counter is 
reset to 1 except when a continuoys forn? is being 
written. A standard header will be written only at the 
beginning of a listing when a continuous form Is 
specified. A specified page width of 132 or greater will 
result in the following heading line. 



FILF C3NTEMTS LIST - WIDE FORMAT 
Columns 1-14 



Columns 
Columns 
Co lumns 
Columns 
Col umns 

Columns 



16-46 

48-53 
55-( 54+n) 



Listing Name or Columns 1-46 
prograiji natie 

Module Name 

System Name 

Product Name (lengthen* n<24) 



C56+n)-{5^+n) Product Version {length«4) 



(fel+n)-89 

<?1-108 



Product Level Clength«5# blank 
f I I led) 

Date Cr Ight justif ied> 
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3.0 OUTPUT 

3«3.2.1 Wi<le Format (132 columns) 



Colynios llD-121 
Columns 123-132 



Tipe Cright justified! 

•PAGE' and Page Number Cright 
justified! 



All unspecified columns contain blanks* 
FILE COMTFHTS LEGIBLE - WIDE FORHAT 



Colu!i5ns 

Columns 
Col ufflns 
Co lujnns 
Columns 
Columns 
Columns 



1-14 

16-46 

48-53 
55-78 
80-83 

85-0*5 

91-108 



Colyains 110-121 

Columns 123-132 



Listing Naiae qt Colunns 1-46 
program nai^e 

Module Na^iie 

System Naffle 

Product Naiae 

Product Version 

Product Level 

Date Cleft justified} 

Time Cieft justified! 

PAGE and Page Number Cleft 
Just I f led! 



The product will reformat ttie standard page format for a 
80 character line. A physical output line format 
greater than the specified line size may be right-end 
truncated by the product to the required specification. 
The excess characters wH I appear on the next line. A 
product may choose to reformat narrow listings within 
the provisions of this document. 

The header format Con terminal fornsatted listings! 
consists of two consecutive lines containing the fields 
defined above In the following positions on lines 1 and 
lines 2. The PAGE and Page Number fields are optional 
for continuous files. 

This information will appear within the following column 
positions of the first print line (Product Name* Product 
Version* and Product Level are left justified* separated 
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3*0 OUTPUT 

3»3«2,2 Narrow Format (80 Colurans) 



by one blank coluinn)? 

FIIE CONTENTS LIST 



line 1 
Columns 
Col yj^ns 



1-14 

16-46 



Colyfisns 48-65 
Colysins 70-^0 

line Z 

Colynins 1-6 

Columns 8-C7-n> 

Columns C9+n> - C12+n> 

Columns {:i4+n> - 4Z 

Columns 48-5 9 

FILE CONTE^ITS LEGIBll 
line 1 

Colymns 1-14 
Columns 16-46 
Colys^ns 48~65 
Columns 70-80 
L ine 2 
Columns 1-6 
Columns B-£7-n> 
Columns C9+n>-C12+n> 
Columns C14+n>-42 



Listing Nam« 

Hodule HBme 

Date Criglit justified! 

Page {right justified! 



System Name 

Product Name ClengtN«n#n • 24> 

Product Version Clength « 4> 

Product Level Clength«5* blank 
fl ll> 

Time Cright justified! 

• 80 Column Format 

Listing Name 

Hodule Name 

Date Cleft justified! 

Page Cleft Justified! 

System Name 

Product Name Clengtli=n* n«24! 

Product Version Clength«4! 

Product Level Clengt^*? blank 
f il I! 
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3.3.2«2 Harroyi Foffflat C80 Columns) 



Cotuiios 48-59 TiJie Cleft justlfledj 

3. 3. 2.3 Ma££aM-£a.£oia.t-i2E-.fiaiiii:Sl 



Tiie header foriiat Con terntlnal formatted listing) consists 
of two consecutlva lines containing the fields defined 
abowe In the following positions on lines 1 and 2* The 
PAGE and Page lyinber fields are optional for continuous 
f i I es. 



FILE COIITENTS LIST 

Line I 

Columns 1-14 Listing Name 

Colyf!?ns 16-46 Hodule Name 

Colymns 49-60 lime Cright justified} 

ColuJisns tZ »PA€E« and Page Nuaiber Cright 

Just I f ied> 

Line Z 

Columns 1-lB Date Cright Justified} 

Columns 20-25 Systei?? 

Columns 27-(26+n) Product Name (lengthen* 

n<24) 

Columns C28+n)-(3l+n) Product Version (length«4) 

Columns (33+n)-61 Product Level {length«5# 

blank f II led) 

FILE CONTENTS LEGIBLE - NARROW FORHAT 

L ine 1 

Columns 1-14 Listing Name or columns 

1-46 program name 
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Co;iy ins 16-46 

Co I w inns 49-69 

Coluttns 6£ 

Line 2 

Colyi^ns 1-18 

Colurons 20-25 

Colun^ns 27-50 

Columns 52-55 

Colymns 57-61 

3.3,3 SOURCE IISTIHG FORMATS 



Hodyle Hnme 

Time Cleft JystlfledJ 

•PAGE* and Page Nyt^ber 
Cleft jystified> 

Data Cleft Jystifled> 

System 

Prodyct Name Cleft 
Jystlfled> 

Prodyct Version Cleft 
justified! 

Product level Cleft 
Jystif led> 



The follOMing standard applies to corapllersj assemblers 
and Interpreters. Asseiiblers mny optionally Insert binary 
i nf orsiat i on at the left of the source statement. Page 
ejects ffiay be suppressed for subseqyent listings of each 
jnodule (e.g. Hap* Cross reference) If the source listing 
is short (e.g. 1/2 a pbqb or less). 

The number of records In the soyrce file should be the 
saflje as the ny^iber of source lines In the soyrce list. 
Therefore^ null records should be capped to all blanks. 
(See section 2.3.2.6.) 



Every printable source listing contains the following text 
In the Listing Name field of the standard listing header* 

SOURCE LIST OF 

— 14 characters — 

A standard source listing header will be written at the 
next top-of-form position whenever the page line counter 
is reset to 1. Only the first source listing header will 
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3.0 OUTPUT 

3»3.3.1 Standard Header Contents 

be *if$tteo on a contlnuoys form* 
3«3.3.2 lilLE.Lilita 

When source twbedded TITLE or SUBTITLE directives are 
processed* the page line counter Is reset to 1 and a 
standard header Is i^rltten* The title text Is printed 
beginning In colufin Z3 and ending In column 132 of the 
line imfiedlately following the first line of the standard 
header* The title lines are followed by a blank line. 



standard header 


— line 


1 


title text 


— 1 Ine 


2 


subtitle text 


— 1 Ine 


3 


b 1 ank 


— 1 Ine 


n 



- 11 (If any) 



n pay take the yalue 3 to 12# depending upon the 
presence of a subtitle lines* 

yhen a source listing Is being formatted for a continuous 
forms the title line Is sl5nply preceded and folloMSd by a 
single bl ank I Ine* 

If a SUBTITLE occurs without a TITLE* a blank line Is 
placed in the position which «ouid have been occupied by 
the TITLE, 

When the source Input module does not contain a TITLE 
direct! ve# two blank lines I filmed late I y follow the second 
line of the standard listing header* 



3. 3* 3* 3 Miilt-Eacffllt 



The actual source statement listing begins on the line 
following the blank line follOMing the header » or titles 
if present. Each source listing print line contains the 
following optional fleldss 

Offset ZC8) A zero suppressed hexadecimal 

number <see section 3.1) giving the 
byte offset In code section of the 
first instruction generated for the 
listed source statement* If this 
field Is supported* It Is selected 
by the list option BO* If 
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3«3«3.3 Wida Fomat 



selected* tlie field must be 
supplied for ail source list in 
I lnes« 



Input Line 

Huwfoer ZCIO) A numerlct zero suppressed nuwber* 

up to 10 characters In length* 
allocated to the source line. See 
section 2*3. 

Left Stateraant 

Attributes x(4) Langyige dependent attributes. 

Right Statei^ant 

Attributes xf4) Coropller dependent attributes. 

The Source Record 
is a required field 

Source Record xC132) Up to the first 132 characters of 

the Input source record* If the 
source line Is less than 132 
characters* this field is left 
justified* Source Code Utility 
CSCU) identifiers are contained 
with In this fleldf If they exist* 

If all fields were present in a source listing* column 
positions would be: 

Columns 1-8 Offset 

Columns 10-13 Left statement attributes 

Columns 1^-24 Line number 

Columns Zb-lZ^ Source (including SCU 

Identification when present) 
Colunins 127-130 Right statement attributes 

If an optional field Is not used the remaining fields will 
be adjusted to the left* 

yhen the source record (26-125) Includes SCU 
Identification Infor^^atlon the following column positions 
will be adhered to for the source record 

Columns 26-10 5 Source 

107-125 SCU identifier* 

The fields should not be changed (mixed) between 
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3.0 OUTPUT 

3,3»3*3 Mide Foniat 



succtssiye uses. Once tlie fields desired are established 
they must remain unchanged. 

existing fields before and after the source record «ay be 
blank. If the source record overflows an additional line 
Is written within the source record field* In this case 
the right attributes field of the first line contains 
»..«' as the first three characters and the rest of the 
field and offset field are blank. The overflow line 
contains blanks In the line nufiber field and the remainder 
of the source record left Justified in the source record 
field. The right attributes field contains the 
information which would otherwise have appeared in the 
first I ine. 



3 • 3 • B . 4 M.a££,aM,«£§£iai-aad -ai-CaiMSG-Efitiit 



The source listing format written on a terminal formatted 
listing consists of one or more output lines for each 
input source record. 

The first line consists of the following fields? 



line Identifier 



Source Record 



Nuweric right justified leading 
zeros suppressed. Optional 
variable width field up to 10 
characters. 

The source record field size Is 
dependent on the file attribute 
ifiaxlffluffi record length and the size 
of the line number field* 



A single blank separates these two fields. 

The source record field size Is dependent on the file 

attribute max Hum record length. 

If the source record Is longer than the Source Record 
field then an additional Line Is written. The lines are 
printed with the same format containing blanks In the line 
Nusnber field and the remainder of the source line 
left-Justified in the Source Record field. 
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3.3*4 OBJECT CODE LISTING FORHAT 



3.3.4 OBJECT CQDE LISTING FORHAT 



Tills is th% format for listing lines of object code 
produced by the coipllers at tlie users request. 
Asseiibiers list tlieir source lines formatted as subultted 
frop the input file. 

Tlie object code listing s^all take one of two forms. Tbe 
first consists of lines describing eacb CY180 instruction 
eeibedded In the source listing and> as far as possiblet 
foHo*#lng the same line from which the code Is generated. 
The object code line shall conform to the standard defined 
below. A group of object code listing lines shall be 
preceded and followed by a blank line* 

In the second forir^t tlie lines describing the object code# 
also conforming to the standard defined below# are 
GoJIectad Into a separata listing* the "object code 
listing*' which st^ail conform to a page foriisat common to 
the listings produced by all compilers. This is defined 
as foi loMS. 

Object code listings consist of instruction descriptions 
and comment I Ines. 

Ins t r uct I on Oe scr I p 1 1 on 

yith the exception of BDP lnstruclons> each Instruction 
emitted is described by a single print line optionally 
preceded and/or' followed by comment lines* The 
instruction description will contain the following fields 
in the following order* beginning in coluiin 2 of the 
I IstabI e output. 



Offset 



7(8) 



Input Line 
Number 



Xtl) 



111119 



A zero suppressed hexidecipal number 
(see section 3*1) giving the byte 
offset of the instruction relative to 
an implementation defined base* This 
base shall be the same base used In 
the offset field In the source line 
{ i f pr ovi ded*) 



The number of the input line for which 
the code Is being generated (as far as 
Is practicable)* 
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3,3«4 OBJECT COOE LISTING FORMAT 



B inary 



xC2) 

XC20 



Labe 1 



tiZ) 



X(31) 



Instruct Ion 



Xt2) 

XCIO) 
8 C 3 ) 



Comment 



XCl) 
X(25) 



An 4j 8 or 16-dlglt lisxaclecl »al ny?uber 
C ad jysted to tlie left) representing 
the binary bit pattern corresponding 
to the generated instruction or data. 
For readability the syggested foria is 
to arrange the numbers In groups of 4# 
separated by blanks* The 4 and 8 
digit numbers are followed by blanks 
to complete the field. For narroH 
format* this field will not be present 



A 1 to 31 alphanumeric character 
string identifying the instruction 
label as defined for the CYBER 180 
assembler* The label field can be up 
to 31 characters In length* It can be 
used in an implementation wanner in 
conjunction Mith the cororaent field* 



h character string Identifying the 
instruction and Its operands* The 
met^cnlcs to be used are those defined 
for the CYBER 180 assembler* The 
junemonlc identifier only may be offset 
by 2 or 4 spaces to distinguish 
particular Instruclons or Instruction 
sequences* (e*g* to Identify code 
generated out of sequence with the 
source*) Operands are specified In 
the order defined in assembler 
specification which appears in an 
Appendix (to be supplied)* As shown 
in the format description* the 
breakdown of the Instruction is as 
foil owss 



HHEMGNIC 



OPERANDS 



X(IO) 

X{3) 

X{21) 



An ImpI eientat I on dependent field 
typically containing user variable or 
label Identifier* register use 
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3. 3,4 0B4£CT CODE IISTWG FORMAT 



cross-references* 

Harrow Format and 80 Column Foriisat 

The narrov* foriat and 80 Column Format consist of the 
offset* line nunber* label* pnenonJc* operands and 
concatenated fields* The binary field will not be 
present. I^ the listed line exceeds 72 or 80 columns the 
line will be continued on the next line (called 
♦'folding**). For PM other than 72 qt 80* the actual width 
specified will be honored! excess information will be 
folded. 



8 dp Instructions 

These are described by a 

by one or two descriptor 

to the Instruction lines 

blank and the operand field contains a descriptor 

forii defined by the assembler specification. 

CoiBient Lines 



line formatted as above* 
descriptions* These are 
except that the iinemonic 



f ol I owed 
s i IS I I a r 
field Is 
in the 



These are used to convey ifiore information than can be 
accommodated in the comment field of an instruction 
description. They consist of a cofsmant field as defined 
for the Instruction description* 



3.3.4.1 Slaaila£ii-Usasl£L-CQCitfiQti 



Every printable object code listing contains the following 
text in the listing Name field of the standard listing 
headers 

OBJECT LISTING OF 
— 20 characters — 

A standard object listing header will be written at the 
next top-of-form position whenever the page line counter 
Is reset to 1. Only the first object listing header will 
be written on a continuous form. 
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3,0 OUTI>UT 

3»3«4»2 Standard Instryctlon Hnewonics 

3 • 3 • 4 ♦ 2 s tiQ4ii:ii«Iasi!:u£tiaa-aaiiiii3l£a 

The instryction menmonlcs used by the compilers will be 

those of the CYBER 180 assembler. 

3«3.5 ATTRieyTES LISTING FORMAT 

A common format for the Attribute/Cross Reference listing 
Is defined hera. It Is yseable by all currently planned 
languages for the Cyber 180 and provides enough 
flexibility to tailor portions of the listing to 
indlirldyal language needs. 

The content of the Attributes listing will wary slightly 
depending upon whether Cross References were selected or 
notf but the essential format will be the saaie. If the 
user selects both attribues and references* the noriaal 
forfnat will be used. When references are not selected* 
the heading will reflect the difference* but the fonwat 
will not vary. If references are selected* but not 
attributes^ then some of the attribute inforisation 
provided will not be listed* providing some additional 
space for references on the line. 

3 . 3 • 5 • 1 Si jQiiJ£il^iisaJtL-Q.aQtfiQts 

Every printable attribute listing or attribute/cross 
reference listing contains the following text in the 
Listing Haffle field of the standard listing header? 

ATTRIBUTES OF 

' 14" characters 

If no attribute list Is selected (cross reference selected 
only) the following text is placed in the Listing Name 
field instead: 

REFERENCES OF 

14 characters 

A standard attribute list header will be written at the 
next top-of-forra position or following a triple space* as 
specified by sections 3.3.1.2.1 and 3*3«1«2«2* and 
whenever following page breaks occur. Only the first 
attribute list header will be written on a continuous form. 
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3*3 .S.! Standard Header Contents 



The standard tiaader Is followed by a biank line and one or 
nore lines containing the attribute/cross reference 
listing heading* This consists of tlie field descriptions 
as defined In the next sectlons# separated by one or more 

blanks. Huiperlc fields In the listing are right-aligned 
with the right-hand side of the description; character 
string fields are aligned on the left* where appropriate* 

Some of the field descriptions way be split between two or 
more lines If requlredf or oislttedj If necessary* as 
Indicated below. 



3.3.^.2 Miil^-£aLiai 



The listing Is made up of entries describing the objects 
defined In the soyrce prograti. Each entry consists of a 
llnsf followed by one or siore extension lines 
!. The definition line gives the line In which 
»as declared Cor first referenced If implicitly 
-. the identifier* and attributes. Extension 
lines are used If there are iiore attributes than can be 
accommodated on one line* and to hold references If 
selected. If both attributes and references are 
the references alnays begin on an extension line 
thesis e Ives. 



definition 
if require 
the object 
dec I ar ed) * 



sei ected* 
by 



The lines contain the fields described in the table below* 
in the order specified. The table also contains the field 
description to be placed In the table heading. The final 
section of the line (for host supplied free form 
attributes nrsd the references) Is continued on extension 
I ines as necessary. 

Entries occur In alphabetical order with a blank line 
Inserted between groups of identifiers starting with the 
same character. Hultlply defined Identifiers are 
consecutive In order of Increasing level of nesting or In 
order of occurrence of block. 

Variable format fields are optional. They are In the 
Indicated order If used* otherwise the field Is not 
present. The sizes for the given fields are mzxlmum width* 



ATTRIBUTE/CROSS REFERENCE LISTING FIELDS 



Fixed Formats 



Field Heading 
identifier IDENTIFIER 



Ize 



Mean I ng 



X(31) The identifier of the entity. 
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3.3.5.2 yide Format 



definition 



DEFIMED 
ON IIME 



XCl) 

Z<5) 



fa I anK 
s I ze 



SUB ynit 



XCl) 
X{3) 



The nape appears left justified* 
blar^k filled. 



The soyrce line nyjuber In which 
the entity i^as defined* or if or 
languages with Implicit 
definitions! first used. It inay 
extend Into the Identifier field 
if larger than five <5) digits* 
The second line of the heading 
-ON LIME- appears only In the 
mide forjBat* 



Size of the entity* in units* 
defined by the host (either bits* 
bytes* or words). The units of 
the size of the entity will 
appear as ••BIT*** ••BYTE^'* or 
"WORD". Abbreviations are BIT* 
BYT* WRD. Norpally the fields 
for size unit coiabi nation will be 



s i ze 

bl ank 
unit 



ZC8) 
XCl) 
XC4) 



If the size field exceeds 6 
digits* then the fields will be 



Sped al 

If size 
the siz 

s Igned 
will be 
SIZE tl 
too I ar 

r I ght* 
grow in 
TYPE fl 
r I ght* 
the IOC 
If the 



size 

unit 
cases 



unl t 
e fie 
Integ 

r Igh 
tie I 
ge* I 

If I 
to th 
eld I 

This 
ATIOH 
SIZE 



s Is 
Id i 
er ( 



ju 

PO 

Is 

TY 

PU 

Is 

fie 

unl t 



ZIIO) 
X C 3 ) 



no-sIze* then 
s allowed to be a 
&4-blt). This 
stifled under the 
sslble* If It Is 
rows** to the 

so large as to 
PE field* the 
shed to the 
possible because 
Id Is undefined 
s are no-sIze* 
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3«3«5»2 yide Format 



b I ank 

type of 
entity 



TYPE 



X<2I 
XCID) 



b I ank 
location 



LOCATION 

SeC+OFF 



XCl) 

Mini mus 
X<6) 



The type of the entity being 
listed. Chosen froB! the list in 
section 3«3#5*4,lj If the host 
wishes fyrther qyal If ications 
listed they appear In the 
attr ibu tes I 1st* 



The location of the entlty# 
where "SEC** Is the section name 
of the section containing the 
data for the Identified 
reference^ and ••off*' Is the 
offset to the beginning of the 
section* The section names areJ 



SLITERAL 
SSTACK 



$PARAHETER 



$STATIC 



SREGISTER 



$8IN0IHG 



The sect 
contain I 
constant 
The sect 
contain! 
that are 
on the s 
the cont 
procedur 
A subset 
SSTACK s 
contain i 
list V a r 
allocate 
stack by 
procedur 
The sect 
contain I 
that are 
al I ocate 
In commo 
not In a 
named se 
Var I abl e 
be long In 
memory s 
ex is t ing 
hardware 
The bind 



ion 
ng lit 

data« 
ion 
ng var 

al loc 
t a C" a 
a I n i n g 
e Is c 

of th 
ectlon 
ng par 
labies 
d on t 

the c 
e« 
Ion 
ng var 

Stat i 
d> are 
nt and 
n expl 
ct ion* 
s not 
g to a 
ectlon 

only 

regis 
Ing se 



era! 



labies 

ated 

hen 

al led* 
e 

ameter 

he 

al I Ing 



I abl es 
c a 1 1 y 

not 

are 
Icltly 



ny 
but 
in a 
ter* 
ct Ion* 
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3»3.S»2 yide Foroat 



Variable Fomat 



SBLANK 

€Y8$0EFAULT 
HEAP 



Blank Cuonaraed) 

common m 

The system heap. 



Code section tianes will be set to 
the name of tlie procedure the 
section represents. User defined 
names of section and user 
declared common blocks wilt also 
be specified In full (up to 31 
characters)* 



yhen 

fit 

al lo 

pr In 

A II 

"bac 

alio 

r ef e 

narr 

if t 

the 

next 

rest 

foil 

re— a 



a "se 

Into t 
cited j^ 
ted# e 
ne fee 
k^ to 
«s con 
rence 
ow for 
he "se 
I Iney 
1 1 ne 
of th 
owl ng 
I I gnme 



c" name is too large to 
he default field size 

the entire nawe is 
xpanding to the right, 
d and re-al Ignisent 
the next listing field 
tinuatlon of cross 
data generation. For 
fflat (section 3»3*5.3)# 
c** naw?e does not fit on 
i t wi J I be put on the 
by Itself* then the 
e raap Mi 1 1 continue 
a i Ine feed and 
nt to the next field. 



For narrow or 80 column format listing the variable foripat 
fields continue on a new line beginning In column 15 and 
extending to colurun 70 or 80. For wide format listing the 
variable format fields continue on the same line beginning 
In column 75. 



Field Head in 
block nu?Dber BLOCK 



b I ank 

nest Ing 
level 



NEST 
LEVEL 



Size 

1999 

X(2) 

ZZZ9PQ 



Meaning 

Specifies the block or subroutine 
in which the object was defined. 



The nesting level of the 
declaration of the entity if a 
block-structured language. if 
the host Is not a block 
structured language* the nesting 
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3 • 3 « 5 . 2 Wide format 



level Is oiRltted. The second 
line of the heading - LEVEL - 
appears only in tlie wide forniat 



blank XC2) 

containing CONTAIN OR XC31I The name of the containing or 
entity DECLARED IN qualifying entity. SlanN If the 

entity Is not contained or 
<iuallfled« The ••contained 
within*' fofii Is for arrays and 
stryctyres. The "declared in»* 
form Is for local variables* The 
entire heading Is on one line. 

blank X(Z) 

basic ATTRIBUTES X(12) The «baslc attribute" of the 
attributes entity Centry# externalf etc.) 

chosen from the list In section 
3.3.5.4.2. Blank if 
non-applicable to the entity* If 
there are no optional fields and 
the basic attribute is not 
present* the whole line Is 
omitted In narrow format. 

Other host defined attributes 
separated by commas. These 
attributes begin on a 
separate line beginning with 
column 54 for wide format and 
column 15 for narrow format 
listings. Each definition 
specified by the host Is placed 
on one line If possible* 
otherwise each that overflows 
starts a new line. If the 
definition doesn't fit alone* It 
is broken at a bl ank« 

references REFERENCES ZC6)XC23 References on the identifier 
For combined line begin at column 54 on* 

map* subheading the listing In narrow format 
will be the first line has two 

references. Subsequent 
"REFS"* lines start In column 15 

starting on and have six references per 

a separate line. In wide format all 



user 


(no heading) 


free 


a ttr 1 butes 




field 
star t~ 
Ing on 

a sepa- 
rate 
line 
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3*3. §.2 Hide Format 

line. Mnss start In coluisn 54 and have 

8 references per line* f^Qt mixed 
aiode listings^ see discussion 
feelow* 

The format for references Is a six digits right 
justified* blank filled Integer^ followed by an 
optional slash if) » folloMed by qualifying letter* 
chosen from the list In section 3.3.5.4.3. This 
coiiblnatlon Is followed by a blank. 

In iRixed fnode C combined attributes and references)* 
both the attributes and references are h^ndi^^ as 
described above* except that the first reference line 
has a subtitle -REFS- placed at Its left. The subtitle 
-REFS- Is placed In columns 9-13 on the narrow listing 
and In columns 48-"!52 In the wide listing. 

Since the user lay select the attributes listing 
separata from the references listing* the following 
changes occur when both are not selected together. If 
attributes only are selected* the references are not 
listed. If references only are selected* the 
Identifier* line number and references fields %t t used 
and the references begin at the end of the first line* 
not on an extension line. 

3.3.5.3 Ma£:£fiM.-££Liai-.aai-ia-i;LalymQ-Eiii:ial 

The narrow format listing will have the sawe format as 
the wide listing with the exceptions noted in the 
descr Ibit Ions In section 3.3.5.2. and with the 
exception that the attributes and refer nces fields will 
continue on an extension line beginning In column 15 
and extending to column 70 or 80. 

3.3.5.4 Staoiiatii-Eifiiii-^iaiygs 



3.3.5.4.1 ENTITY TYPES 

Each entity Is assigned a basic* cr oss~l anguage type. 
These appear In the •'Type'* field as one of the followingi 

TYPE ABBREVIATED FORM 

Simple var* VAR 
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3,3,§,4,1 ENTITY TYPES 



Array# ARR 

Structuref STRU 

Heriber.# HEH 

Condition* COND 

Constant* CONS 

Type# TYPE 

0£F# OEF 

Pr ograrif PROG 

Module MOO 

ProcedyrSf PROC 

Function* FUNC 

Label* LAB 

Switch^ S^CH 

FIta* FILE 

For^^at* FHT 

Paragraph* PARA 

Section* SEC 

Impi naiPi* (for Implewentor name) IHPL 

Group* GRP 

Alias ALIA 

Error ERR 

Attr nawe* ATTR 

Each host need not support all types of entities on this 
list* but should define a consistent mapping Into a subset 
of the above. The final entry (••Error**) should be used 
for entities whose definitions contain syntax errors 
sufficient to prevent the compiler froa? determining the 
user's intentions* 



3.3,5,4.2 BASIC ATTRIBUTES 



This field contains attributes basic to the entity 
definition which are exclusive of one another* If the 
entity does not fall Into one of the following catagories 
of attributes* then the field is left blank. Tfiese ares 

Attribute Abbreviated Form 

undefined UNDEF 

unreferenced UNREF 

EntryPoInt ENTRY 

External EXTRN 

None (field Is blank) 
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3,0 mrpm 

3,3. 5.4. 3 REFERENCE TYPES 



3. 3. 5. 4*3 REFERENCE TYPES 

The standard reference type abbrav I atlons will beJ 
n the entity >«as set Cisodlfled)* 

(blank)* the entity was used (slash Is also omlttedl 
A the stateipent defined an entity attribute* 
S the entity was a subscript or Index* 
I the entity (usually a fllel iias referenced In 

an I/Q statement 
R the entity was read Into (or* If a file* was 

read) 
W the entity as written frof» Cor* If a filCf was 

wr I tten) 
P the entity was used as an actual parameter 

For all listings containing references there Is a legend 
of the possible reference types and their one character 
abbreviations at the bottom of each page* This legend is 
right justified and takes the forsi abbrev « full naee* ••«• 

for exanpie? H»modlfy» A*attrlbute* S«sub script* 
1=1/0 ref* Reread* Wwrite* P«paran5* 

Each host nay choose to use the entire set or a subset 
thereof f but It is hoped that Jiost hosts will use the 
entire set* 



3*3.6 DIAGNOSTIC LISTING 



The diagnostic listing for compilers* assemblers* 
interpreters* etc*f consists of diagnostic Bjessages. 
Diagnostics are listed in either of two modes* at the 
host's choice. The first method lists ail diagnostics and 
a diagnostic summary at the end of the listing* following 
the Attribute/Reference list (If selected). The second 
nt?€thod lists syntax diagnostics In the source listing as 
they are detected* with later (non-syntax) diagnostics and 
the diagnostic suromary being listed at the end of the 
Attribute/Reference list. If the first method Is 
selected* the host may also choose to have the location of 
the diagnostic occurrence flagged in the source listing 
(by means of a caret symbol under the offending column). 

When compilation occurs with zero diagnostics a diagnostic 
summary will be produced consisting of the single line »N0 

ERRORS'. 
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3,3.6 DIAGNOSTIC LISTING 



3 * 3 #6 .1 ltMniMtdJi^^ski.^Z.Qnt&nts 



Every printable error M st i ng/sufumar y contains tlis 
following te^t in the listing name field of the standard 

listing header 5 

mmR LIST OF 

-—14 ,chtr acters-"— — 

A standard error listing header i«lll be siritten at the 
next top-of-fors position or following a triple space# as 
specified by sections 3»3»1«2«1 and 3«3»1«2«2# and 
wfienever a subsequent page break occurs* Only the first 
error listing tieader Is written on a continuous forw. 



3 • 3 • 6 • 2 atBQlil£4-.fiiia!ia& tl£-LiatiQII-£ilLltl 



All diagnostic listings^ whether grouped together at the 
end of the other listings or printed intermixed with the 
source listing will have the same basic foriiat* When 
grouped* they villi be listed in source I ine/stateiaent 
column/diagnostic number order, yhen grouped and the 
diagnostic number Is not being printed* they will be 
listed in source I Ine /statement column/order of issuance 
order* When printed Intersil xed with the source Mstlngf 
they will be printed In the order the host detects then?. 



Column positions 
fields are used* 
is not used* 



are specified for the case where all 
nnd remain the sauie If an optional field 



Column 

Position Contents Format 



1-9 



11-17 



ieyel XC9) 
line n r * Z { 6 ) 9 



22-24 



diag* no* ZZ99 



Meaning 

error severity level of the 
d i agnostic 

source statement number on 
which the error occurred* For 
diagnostics intermixed with 
the source listing* this field 
contains *ERRQR** 

diagnostic number of the error 
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3*3 •6» 2 Standard Diagnostic Listing Forjnat 

Casslgr^ed by the host)* This 
field is opt ional « 

26-28 COL X(3) The abbreviation for the ^ord 

colupr> in ifiterj»lxed siode* If 
the colujun number field 
contains zero* «COL' Is 
suppressed. In grouped mode 
this field contains the column 
nupber described belowt and 
that field Is blank* 

30-32 cof* no* ZZ9 column number In which the 

error was detected* Blank If 
not applicable* In grouped 
jiode the column number is 
present In the col <26-28l 
field and the coluRin number 
field Is blank* 

34-eol text the diagnostic text (defined 

by the hosti* Each word 
within the text Is separated 
by one space and the line is 
filled as required* Extension 
lines begin with the text 
position through the end of 
the line* single-spaced* In 
Interfflixed iode# the '«'ERRQR* 
indicator is re- is sued on 
extension lines* 

Diagnostic summary for products that use diagnostics 
Intermixed with source should include a page list of pages 
with diagnostics* 

3.3.6.3 Si;aadi£i2«I2iaaaasti£«SiiiffliiL3t-.£iJL!flit 

The diagnostic sufumary will follow the diagnostic listing 
for grouped di agnostics* or stand-alone for intermixed 
diagnostics. In either case It provides the user with a 
summary of diagnostics detected and listed* as directed by 

the EL parameter. 

There will be an diagnostic suminary line for each level of 
diagnostic detected during the compilation* If no 
conRpiiation errors <at any level) were detected* then that 
is noted. The following format will be used for all of 
the summary 1 1 nes^ 
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3.0 OUTPUT 

3«3«6»3 Standard Diagnostic Symwary Format 



colyrans 3-6 **** SuP?»ary line flag 

coluiins 9-1^ Ny^ber of diagnostics of a 

given category^ In the format 
ZC5)9, 
ccluiins 16-sol Text* In the forwat •*aaaa 

dl agnost I cs"* where aaaa Is 
the category being 
suffiinarized. If the 
diagnostics were not listed 
(due to €1 setting) then 
"(unlisted)" Is appended to 
the i^essage. 

If only one diagnostic at a given level was issued^ the 
word "diagnostics** ♦* i 1 1 be "diagnostic" In the messages* 



3.3-.7 COHPILATIQN OPTIONS 



The coni5pllers i^lll produce one or more lines of output to 
indicate which control statement options mtre selected for 
this compile (either by default or explicitly)* The 
format of this line will reflect section 2*2 of this 
standard. This line mHI appear after all other listings 
for each module* It Is produced whenever any list option 
is selected and not produced for 10«H0N€» 



3.4 £RaQE.-l3£SS4££S 

This section describes conventions for ail ASCII error 
niessages. This Includes log messages (to system and Job 
logs)# interactive massages^ and error fnessages written to 
the OUTPUT or other files (reference Jogs* section 3«2)» 
The conventions Include the use of the Message Generator* 
message Identification* and message wording. 

3.4.1 MESSAGE GENERATOR USAGE 

The NQS/VE Message Generator is used to foriiiat and output 
all error messages output to logs or to an interactive 
users terminal (note this does not Include diagnostics 
generated during compilation). It produces a standardized 
message using the MOS/VE status record and message 
templates from a n^essage dictionary. 
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3^0 OUTPUT 

3*4.1 HESSA^SE S£nER4T0R USASi 



A sufwary of tha NOS/VE status record fields Is noted 
beiOM. TNe NOS/VE ERS should be referenced for a coaiplete 
description of the status racord and the Message Generator 
Interfaces. 



Nonpal - k boolean which has a value 
could not be processed correctly and 

processed correctly. 



of FALSE If a request 
TRUE If It has feeen 



Identifier - The two character product Identifier 
associated iiltN the product generating the status record. 
The Identifiers are as defined In sections 4»1#1»1 and 

3.4«1#1 of this docufjsent. 

Condition ~ A six diait unl<iue systems wide code indicating 
the specific error. The values for this field are defined 
by each product according to the conventions specified In 
the folloviing section. 

Text - A string used to substitute text Into the error 

flraessage tersplate associated *«ith the condition. The first 
character of the text signifies the character used as the 
text delirpiter. All text Iteips are terminated by the 

deliislter or the end of text. 



3.4.1.1 staQia£d.iIasilitlaa-£aias 



To guarantee generation of unique system wide condition 
codes* a range of nu»?foers are assigned for each product. 
Each product must assign codes within that range and 
deterijiine the inessags teniplate to be associated with that 
code. Product Identifiers are as assigned in 
section 4.1.1.1 and are repeated below. 

All CCM and CCG errors will be reported using host 
condition codes. The codes to be used are chosen by each 
host. A host !i»ust provide at least 250 condition codes 
for reporting CCH errors and 250 codes for CCG errors. 
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3,0 OUTPUT 

3*%#1.1 Standard Cofidltlon Codes 



Cond 1 ti Qn 


Code 


1 


.m. 


159,999 


160#000 


— 


169*999 


ITOfOOO 


-. 


179*999 


IBQtQQO 


- 


189*999 


190#000 


« 


199*999 


200*000 


-. 


209,999 


21O#OO0 


« 


219*999 


2ao*ooo 


- 


229*999 


2 30#000 


«. 


239*999 


240^000 


- 


249*999 


250*000 


- 


259*999 


260^000 


- 


269*999 


2?0#000 


-. 


279*999 


280#000 


- 


289*999 


290,000 


- 


299*999 


3 00 > 000 


- 


309*999 


310*000 


- 


319*999 


3 20*000 


- 


329*999 


330*000 


- 


339*999 


340*000 


- 


349*999 


350*000 


- 


359*999 


360*000 


- 


369*999 


370*000 


- 


379*999 


380*000 


— . 


499*999 



Product 
I d a n 1 1 f I s r 

Reserved 
AH 

JH 
LI 

HH 

OS 

PF/FS 

PH 

R.H 

OF 

AV 

IC 

oc 

OS 
HS 
IF 
US 
SF 
CH 
HU 
NA 
Reserved 



Product Nawe 

Basic Access Mettnods 

Cofflmand Language 

Job Hanageinef^t 

loader 

Hemory ManageiBent 

Operating Systero 

Per juanent File Hanageroent/F H e Systei^ 

Prograii? Hanageiaent 

Resource flanagement 

Operator Facility 

Account I ng/Vall d at ion 

Interstate Communication 

Reiiote Host Facility 

Object Code UtI ! itles 

Deads tart /Recovery 

Maintenance Services 

Interactive Facility 

User Ce#g«* for "user'* statistics) 

Statistics Facll I ty 

Configuration Hanageroent 

Help UtII Itles 

network Access Hethod 
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3«0 OUTPUT 

3,4«1»1 Staiidard Condition Codes 



500,000 


— 


509*999 


kk 


510*000 


^ 


519,999 


ES 


3ZQfQm 


« 


529,999 


hi 


530*000 


- 


539,999 


k? 


540,000 


- 


549*999 


8C 


§50*000 


- 


559,999 


DA 


560*000 


- 


569*999 


C8 


570,000 


- 


579,999 


CY 


580*000 


- 


584,999 


FC 


585*000 


- 


589,999 


Ft 


590*000 


- 


599,999 


?k 


600*000 


- 


609,999 


PI 


610*000 


- 


619*999 


SH 


620*000 


- 


629,999 


SC 


630*000 


- 


639,999 


FN 


640,000 


- 


649,999 


DB 


650*000 


- 


559,999 


HP 


660*000 


~ 


669*999 


HA 


670*000 


- 


679,999 


HL 


680*000 


- 


689,999 


in 


690*000 


- 


699,999 


ST 


700*000 


~ 


709,999 


LI 


710*000 


~ 


719*999 


FA 


720*000 


mm 


729,999 


AD 



Advanced Access Metfiod 

Edit Screen 

Assembly Language 

APL 

BASIC 

OCN Dui^p Analyzer 

COBOL 

CY8IL 

FORTRAH COMPILER 

FORTRAN LIBRARY 

PASCAL Cyirth) 

PL/I 

Sort Herge 

Source Code UtI I i ty 

FMU 

Debug Faci 1 1 ty 

Hardware Perforrpance Analyzer CHPA) 

Maintenance Application Language 
for Equipment Testing {HALET) 

Hatfi Library 

Information Management Facility 

Software Tools 

LISP 

File migration Ai ds 

Ada 
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3,0 OUTPUT 

3*4 « 1.1 Standard Condition Codes 



73O.f0OO - 739,999 
740#00a - 749,999 
750,000 - 759#999 
3. 4,2 HESS^SE TEXT 



FV 
VC 
VX 



CDC FORTRAN < Sector iz Ing) 

C cempl ler 

¥X/VE - UNIX Efiulator 



The iisessage teiplates are detemlned by each prodyct and 
Included In a message dictionary. The NOS/VE ERS should 
be referancsd to determine the forraats of niessage 
tewpl ates. 



3.4.2.1 Massias^EfiniJits 



The message generator foniats and outputs messages 
according to conventions based on the message's 
destinationJ terfulnal, log, file, or returned to the 
cal I er . 

Terminal ! 

Formats text «♦•** or IDnnnnnn text «••«• 

Examples Perraanent file Cpfu) not found. 

Log, OUTPUT, or other files 

Forniats IDnnnnnn text •«••• 

Examples CB0326 Incorrect delimiter, cojuroa 

assusKed* 

Returned to callers 



Format s 
Ex amp I es 



y h e r e s 



text . . « • • 

10 

nnnnnn 



SIO 



IDnnnnnn SID minm text .«•** 
AH1234 SOP 012 File (Ifn) already 

opened* 



Text of message 

Product Identifier 

The error condition code 

(unique error number for a given 

product) 

Product sub identif ier 

Subcondltlon code. 
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3.0 OUTPUT 

3«4.2.»1 Hess age Formats 



The combination IDnnnnrsn will be kr^own external iy as the 
"C180 error nyfnber". It is a unique systera-wlde code by 
which any error message can be Identified to the user. It 
Is always printed before the message text on all batch 
listings* It can optionally be Included with messages 
output to an Interactive terminal and is available to the 
terminal user requesting additional error analysis 
assistance via the NQS/VE HELP facility. 



3. 4. 2. 2 £££a£.«SMiia£isa-iQ-Laaa 

When error summaries 'a^r^ listed on a fiie» log messages 
should be Issued to both the systew and user log according 
to the following rules and formats J 

.Syste?» and User tog 

n fatal errors CIn x3 
User Log Only 

n learning or trivial errors Cin x3 

n nufflber of errors 

X Is the nasje of the wodulej progra!^* subroutine 
that contains the errors. 



Error summaries should only be used when It Is 
inconvenient to provide a description of an actual 



error. 



Catastrophic errors are not included because they should 
always result In a log message indicating the catastrophic 
error. The error counts should be Issued to the log even 
if the EL Cerror level) parameter excludes thesn from the 
listing. 



3.4.2.3 Has&ia£-.lii2Liiaa 



Error messages represent a very important^ though often 
neglected* Interface between softvtare and user. Proper 
attention to producing polite* correct* and clear error 
messages can do a lot toward improving the overall 
usability of the system. The following conventions should 
be used In defining error message texti 
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3.0 OUTPUT 

3»4.2«3 Message Wording 



Hessages should be polite and courteous* Words such 
as •'Illegal'* should be avoided In favor of words like 
"Incorrect** or '"unknown". Error messages should^ 
Mhere appropriate* suggest what the user ought to do 
to correct the error. For exaaplef useJ 

The line nuinber parameter wust be an Integer* 
notJ 

Illegal line number. 

Messages must be formatted for 72 character displays. 

Telegraph style Is fnuch better than long-winded 

prose* Ho^B'^Brf the message nust be descriptive of 

the error. Messages like "Bad Argument*' don't say 

enough. 

Consistent ternilnology Is 

systaJi-*«lde teras consult 

terminology specific to a 

is the Important factor. 



extremely important. For 
Section 6.0 of the SIS. For 
products again consistency 



Identification iBust be provided with variable 

inf orniat Ion. For exas»ple! 

uset 

File { If n) not found. 

Variable Cvar) must be scalar* 

not? 

C I f n) not found* 

Variable (var) must be scalar. 

Use ending punctuation* It Indicates to the user that 
the message Is not continued on the next line and adds 
to the readability of the message. 

Hessages should be oriented toward an Inexperienced or 
casual user such that the message can be understood 
and appropriately responded to without reference to a 
p; a n u a I . 

Abbreviations should be avoided. Mhenewer possible 
limit the characters used to a Iphanuraer Ics plus 
englisfi punctuation. Avoid use of characters that 
appear differently on different devices. COC's 
64-char3ct9r ASCII subset and lowercase al phanumer Ics 
can be used. 

Words beginning with "fpultl" and "non" are not 
hyphenated. Don't use 'Ms)" to Indicate an optional 
plural usagej either singular or plural is acceptable. 
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3,0 OtlTl^yT 

3*4*2. 3 Message Wording 



• Error messages sliould yse uppnr and lower case as they 
are nornjally ysed In the English langyage* Upper case 
should be used to dlstlngylsh ♦•coisputer** words from 

normal English Hords* For exanipleJ 

File FRED not found* Specify keyword NEy. 

All products are re^^ulred to collect and log statistical 

I nf oriiat ion» 

This section describes what these statistics are used for# 
the NOS/VE Statistics Facility* *«hich statistics mIII be 
collected by products and which will be collected by the 
0/S and when statistics shoyld be logged. 

Because the Statistics Facility Is under control of HQS/VE 
product designers are requested to convey statistics 
reqiulrements and plans to the NOS/VE design teaiR* 

3.5.1 PyRPQSE OF STATISTICS 

Statistics logged by products may be used for billing^ 
nfieasurlng rail ability* measuring per forwancet debugging* 
product planning or sope other purpose. The ultimate use 
of the data cannot be determined when the product Is being 
designed. For exaruple* a statistic such as **nufliber of 
source statements compiled"* which Is normally considered 
a performance statistic* could Just as easily be used as 
the basis for charging or billing a user. It's not 
Inconceivable that a student could be billed based upon 
(number of source statements) " (number of comment lines) 
■♦• n * (number of errors) If this data were available for 
each con?pi le. 

There are three physically different logs for recording 
statistics* They are the accounting* Job* and system 
statistics logs. See section 3*2. A particular statistic 
may apply to one or all three of these logs* To prevent 
products frorn having to issue the same statistic several 
times* to prevent product designers from having to decide 
which statistics will be used for which purpose* and to 
provide installations and users maximum control over 
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3,0 OUTPUT 

3,5.1 PyRPOSE OF STATISTICS 



statistics gathtring* NOS/Vi provides 

Statistics Facll lty« 



a central I zed 



3,5.2 STATISTICS FACIIITY 



NQTE! This Is p rel liiilnary iof orwat ion. The NOS/VE 
ERS sfioyfd be refereficed for a more complete 
and up to date specification. The ERS Is the 
coritrollinf docyfl?ent for this product to 0/S 
Interface. 

The NOS/VE Statistics facility Is used by products and the 
0/S to accyfflulate statistics and write records Into binary 
1 ogs* 



The Statistics Facility 



associates a statistic code from a status record with 
a particular table entry 

adds Job and task Identification to the varlahle data 
If appropriate. Task Identification specifies Mhich 
of the possible several asynchronous Instances of 
execution Mitfiln a job the current statistic belongs 
to. 

- routes the statistic to the appropriate log or logs 
and/or adds it to a specific counter as determined by 
the table entry. Counters can be dumped to binary 
logs at specific times or events. 

Data passed to the Statistics Facility Include: 

statistical code ~ ordinal of this particular 
statistic. 

optional byte string - for products this string 
contains product ID# module identifiers If 
appropriate* ami any other product or statistic unique 
descriptive data. Product ID Is the two character 
Identifier defined In section 4.1.1. 

optional count fields - to n numbers* the numeric 
part of the statistic. 

Data returned Includei 
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3,0 OUTPUT 

3.5*2 STATISTICS FACfllTV 



Statys - boolean ir^dlcatJng whether or not the 
previous Statistic Facility request was processed 
correctly* 

Tlie jiethod for assigning statistics ordinals will be 
specified In the ERS* .A separate range of nuibers will 

probably be reserved for users* 



3*5.3 PRODUCT STATISTICS COILECTED BY HOS/VE 

In general^ the 0/S Is responsible for collecting job step 
statistics that can be daternilned external to the product* 
that Is statistics that the 0/S is capable of determining* 

For each product Identified in SIS section 4*1 that Is 
directly invoked by the user* €*g*> via coniraand or ^s a 
program Initiated task* NOS/VE will record resources used 
per Invocation* Resources accounted for include? 

total CP-tlfiie 

iPaxiiuuii virtual memory used 

- maxinuai real memory used 
average working set size 
CP-tlffis per memory size used 
number of I/O requests 

amount of data read/written to files 

Additional data to be collected for each Invocation of a 
product include* 

- origin of Job step - batch command* terminal comrRand* 
procedure flle# executing Job* 

~ type of termination - normal* product error* time 

limit* Invalid memory request* operator drop* etc* A 
recovered condition does not cause product termination* 

average interactive response tliue for interactive 
products - the average elapsed time between input data 
available and output data Issued to terminal* 
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3.0 OUTPUT 

3.S.3 PRODUCT STATISTICS COllECTiO BY NOS/Vi 



ttie fact that the product i^as invoked <add 
of tfis r^ufiber of ssparate Ir^vocations) • 



to count 



number of nodyles loaded < Input units for the loader) 

source lafi§yages of modules loaded (added to language 
usage cauntl. 



disk accesses per CP second* 
These same statistics/ resource usage and additional data* 
way be collected for any user initiated job step whether 
it Is a user supplied proaram or a CDC supplied product* 
Statistics for products «i I I be identified by product ID* 
correction level Information* and task number acquired 
during loading* 

Task nufiber Identifies which invocation of product x 
Issued the statistic* Several asynchronous tasks way be 
executing the same product* Statistics for user written 
tasks may be Idantlfiad by primary jnoduie name* task 
number* and other data gleaned fron? the file ID* 

Nujnber of invocations will be collected for all products 
both user called and product called service products such 
as Access Methods* i^n4 all user tasks* It could be 
collected for all modules on system libraries* For 
products* it represents the number of times the product 
was Invoked over a given tii^e span; for user programs It 
represents the number of times a program module written In 
language x was used over a given time span* The tl^e span 
is installation definable* 



3.5.4 STATISTICS COllECTeO BY PROOUCTS 



In general* products are responsible for collecting 
internal statistics that only they can know* There are 
two classes of product generated statistics - Input units 
and internal usage statistics* 



3 * 5*4*1 iQfiMt-yalt-Statiatifis 



This class of statistics is concerned with the number and 
nature of user controlled data processed by the product* 
The number of Input units is what PIOFR (Product Input 
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3.0 OUTPUT 

3,5»4.1 Inpyt Unit Stitlstl€S 



Data Fallyre Rate) calculations are based wpon» All 
prodycts are required to log n«mber of input units 

processed par Invocation* 

Section 8«6.2 of the AO/R CARH 1688) defines input units 
for various Products and C/S levels. In summary they ares 



Product 

language translators e.^g** 
FTN# C0BOL# CYBIL* DDL 

Utilities such as SQRT/HERGe# 
FHU* EDHS util iti es, OCU 

Ser¥lces such as AH* AA^ 
and OHSlSD's Query service 



Input Unit 



Source 
I ines 

Data records 



Funct i onal 
requests 



Input unit related statistics other than count which are 
required where applicable^ Includes 

Language Translators 

- nuiber of lodules processed 

- number of declarative stateisents 
~ number of executable statements 

- nufuber of conswent and blank lines 

number of source statement errors for each error level 
UtI I ities 

- number of type n records 

n = each recognizable record type supported by the 
product 

number of records In error 

~ merge order used 

average key size 

- average key type 
Services 
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3.5*4«1 Ifjpyt Unit Statistics 

nufflber of functions of type n 

nujRber of II legal /i 1 l-foriued requests 
Hany ott^er potentially useful Input related statistics are 
possible* Products developers are encouraged to collect 
additional input statistics they feel are worthKhl I e» An 
exapple Is source statement frequencyt l»e** number of 
each type of source statement encountered* 

3.5.4.2 iQi:£i:aai-.Statistl£s 

This class of statistics Is concerned with Internal 

measures of tbe product as opposed to measures of the 
Input data. These statistics report internal product 
information that the 0/S Is not aware of* 

Examples of such statistics are? 

product options In effect for this execution e*g*f 
what control stateicent parameters mere selected* 

internal errors encountered 

Products are required to log options used and nuasber and 
type of internal errors encountered* The other statistics 

Bre highly desirable and should be collected at least on 
an optional basis* 

Hany additional statistics may be applicable to specific 
products. Developers are encouraged to collect other 
statistics they feel are worthwhile. 

3.5.5 WHEN TO LOG STATISTICS 

The two issues of concern ares 

when should detailed optional* statistics be 
accumulated and logged? 

when should subordinate service products such as AA 
I og statist! cs? 

All statistics will be controlled by Installation or user 
controlled switches. The statistics Facility will provide 
the fnechanism for setting and clearing these switches. 
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3«0 QUTpy? 

3.5,5 mm TO LOG STATISTICS 



Each procsdyre tliat issues diagnostics must check the 
appropriate switch before calling the statistics 
Facility. The switches will probably exist as an array of 
bits that can be referenced but not changed by us^r 
tasks. The NOS/VE ERS will specify the exact forfli. 
Subordinate products and routines may either issue 
continuous statistics at product determined Intervals or 
events or they fsay accu^iulate and report theia under 
control of the host product* 

For products such as AH and AA whose statistics could be 
peanlngfyi regardless of the host* the first approach Is 
acceptable. For example* statistics could be gathered 
from file open to file close for each file. Anyone 
interested In AA statistics for a Job step would have to 
sum up the Individual statistics on the log file* 

For subordinate products and routines such as the coiifaon 
compiler modules whose statistics are not meaningful out 
of contexts a laechanls^ should be provided to enable the 
host to force out statistics on deniand. That Is* the host 
must be able to Inform the subordinate that Its work Is 
cofpplete. If the subordinate actually Issues the 
statistics* the host wust provide Its product ID to the 
subordinates so that 10 can be included In the 
statistics. If the host actually Issues the statistic* 
the subordinate ?iust return ail data and Identifying 
information. The first method is preferred since the host 
does not need to know which or how many statistics the 
subordinate Is collecting. 

Note that all ?nethods of statistic reporting require 
products to recover from catastrophic external and 
internal errors. Products must regain control so that 
they can output the accumulated statistics. Furthermore* 
since 0/S logs the reason for terailnat Ion* products that 
recover from abnormal external conditions must be able to 
let the abort happen after they issue their statistics so 
that the correct reason for the termination is recorded. 
Products that detect Internal errors must be able to 
Indicate that such an error happened when they abort* so 
that ••internal error** Is recorded as the reason for the 
abort. A product may choose to terminate via an abort 
when no product error has occurred. 
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4,0 SYSTiMyiDi CQNVEMTlOf^S 



4.0 siii£aiiia£.i;Qtii£iii[itis 



Tliis sectiofi describes the operating systaai and product 
set convention which myst be followed by all standard 

software* 

The term "global** as ysed in tills section refers to 
constant and type definitions that are global to several 
products. It does not roean ♦'global** within a particular 
produc t. 



4.1 MM£ii..MI£i-.4Ma-II!l£S 



Standard s^^stei nailing conventions ^re needed for the 
f ol loMing reasons? 

1. Perpit recognition of the origin and maybe the purpose 
of the naied entity Just by its nanse* 

2. Prevent duplication of names between different 
products. 

3* Designate categories of naipes that are reserved for 
CDC usage so that thay Mill not be duplicated by 
application progr at!?n3ers* 

These nanes lay be declared as entry point names* file 
najisesf SCU deck names* or as names for comnjon system 
entities such as Installation options* The common system 
entity names iiust be declared In a form that provides a 
slsipie source of availability for use by any system 
implementation language* CCYBIL or assembly). 



4.1.1 NAMING COHVENTIONS 



The system defined global names will be generated 
according to the following convention? 

PPCSXXX 

where? 

PP — is a Z character alphanumeric product 
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4»0 SYSTEflMlDE CONVENTIONS 
4a. 1 ^AMINI5 CONVENTIONS 

identifiar or other global identifier for the 

ownar of this syinbol* 

C — Ider^tlfles the class of the nawe. 

$ -~ I s the special character $ 

XXX — - 2 or ipore alphanyjier Ic characters which 

establish yni<|ueness within the levels of 
Iderjt If Icatlon described above. The laxliRum 
length of this field Is deterialned by the other 
users of these naises, Exaiple« The loader 
determines the raaxlpufn length of an entry 
polntf the record iianager the mz%\mum length of 
a f i I e naps* 



4 • 1 . 1 • I EHfi^iifit-Id^Etif laLS 



AA Advanced Access Hethod 

AL , Assembly langyage 

AH Access Method 

AP API 

AV Accounting Validation 

8C BASIC 

CC CoMon Conipiler Hodyles CCCH) 

C8 COBOL 

CS Coipmon Code Generator CCCG) 

CI Coiafiand Language 

CM Configuration Hanageiient 

CV CYB€R Automatic Vectorizing and 

Langua<ie Independent Coajpller (CAVALIER) 

CY CY8IL 

OA OCH Dump Analyzer 

08 Interactive Debug 

OS Deadstar t/Recovery 

ES Edit Screen 

FA File Hlgratlon Aids 

FC FOPTRAM Coipl ler 

FL FORTRAN run tln?e Library 

FH File Management Utility 

FS Fl le System 

FT FORTRAN. Global to FC and FL 

FV CDC FORTRAN (Vectorizing) 

\^? Hardware Performance Analyzer (HP A) 

m Help LItl lltles 

IC Interstate Communication 

IF Interactive Facility 

IM Inforn^at Ion Hanageruent Facility 
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JH Job ?^ana9®ient 

LI LISP 

LL loader /| Ibrary generator 

HA Halntenance Application Language for Equipment 

Testing CMALET) 

HL Hatti LIbrarV 

MH Hemory Hanagsiient 

HS Halntenance Services 

MA Hetnork Access Hethod 

QC Object Code- Utilities 

OF Operator Facility 

OS Operating System 

PA PASCAL Cyirth) 

PF Periianent File Hanagewent 

PH Prograip Management 

PS Prodyct Set 

PR PROLOG 

PI PL/I 

QU Query Update 

RH Reroote Host Facility 

R,H Resource flanageraent 

SC Source Code Utility 

S£ Set Hanageiant 

SF Statistics Facll Ity 

SM Sort Merge 

ST Softs^are Tools 

S¥ Shared Variables Processor 

US User Ce,g»» for **user** statistics) 

VC C CoippI ler 

VX VX/VE - UHIX Emulator 



R A R e I e as 8 Ad 1 1 n I s t r a t qt 

This product Identifier Is used to identify 
Installation parameters and procedures associated 

with a HOS/VE product. 

Tbe following list of Identifiers naming classes Is used 
for code and deck naming purposes! 

A — Architectural and Design documentation 
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4 ■•1*1 ,3 Classes of Ma«es 



8 — Design docunsentat i on {internal to CDC) 
C — constant 

— daclaratlon (decks containing types and/or 

constants) 
E — - exception condition narue 
F — f M 3 

1 -'- inline text or code 
K — kaypoint or keyword 
H — modu I e 

P — procedure 

S «.«. section Cstatic data section and/or coupon 

block) 
T — type 
V — varl able 
X — XDCL'd (decks containing procedures or 

var I abl es) 



4 . 1 * 1 • 4 aatiiiii-£iia£j£tai:a 



The use of the $ sign in a name identifies the nawe as one 
belonging to CDC. COC users will avoid any duplication 
with COC names by not using the $ In any of their naiRes. 

Some prograiiffling languages such as FORTRAN do not aHo« 
iiibedded dollar sign characters in their names* CDC 
supplied procedures callable frop these languages will not 
conform to the $ sign rule. 



4 • 1 • 1 • 5 liaiiaia-£yiJi£liQ£a 



Relationship of Code and Deck nasnes 

The deck nanje fnust ha the same as the code name whenever 
possible. In Instances where it Is absolutely necessary 
to group typesf constantsf etc. in the same deck* then it 
is alienable to use a conglomerate deck nafl?e which is 
different than the component code names. 

♦♦Design Docu«nentat I on*' Deck Nai^es <A and 8) 

Class A decks are for architectural and design documentation 
releasable with the code. 

Class B decks are for requirement/design documentation not 
releasable tilth the code (e.g.* OR-type specifications* such as 
performance) but relevent to code oialntenance. 
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A "design docuraentat 
TRUE or FALSE* depeii 
of thi s deck and al I 
procsssor named in t 
Is in th% torn of a 
processor Is Invoked 
compiler l3yt rattier 
docyipsntat ion decks 
PROCESSOR wight be T 
processed on tNe C18 



lon»* deck has the EXPAND attrlfeyte value of 
ding ypon the needs of the product. The content 

decks *COPyed by this deck are Input to the 
he PROCESSOR field of the SCU deck. The PROCESS 
string wiiich represents the command by i^hlch th 
• Docuiaantat ion decks lay not be processed by a 
by a text foriaatter processor. For Instance* 
rwlght be processed on the CI 70; then the 
XTCQDE* In the future^ documentation decks pay 
by a text processor* 



Documentation decks not to be released to custojners myst be 
Identified (by group) by the development project to Integration^ 
which will refuovs such decks during preparation of SHD release 

fsater I als • 

"Coiip liable" Deck Naies in. and F) 
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M class decks contain 
unit**. Exasiplas of s 
HODENO for CYBIL* IDE 
END for FORTRAN^ etc. 
which are maintained 
environment. A paren 
and P (or V) decks wh 
association* the narue 
a GROUP attribute of 
modifications inade to 
ability to generate t 
GROUP attributes of t 
which *COPY the chl Id 
the INClUDE^CnPYING.D 
name associated *»lth 
specified on the HODU 



as an EXPAND attribute value of 

this deck and all decks *COPY€d by 
o the processor named in the 
e SCU deck. The PROCESSOR field is 
ng yhlch represents the comwand by 
s invoked. Parameters which are to 
assor# and which are meant to be 
tielzatlon levels or debug level)* 
Is string. The order In which 
are specified is precisely the order 
ined for the coiamand* even though the 
led as equlvalenced paraneters. File 
owed in the processor string* 

a processor defined "compilation 
uch compilation units arei HOOULE to 
NT to SNO for ASSEHBiE* PROGRAH to 
Hodule decks represent the units 
In a Binary Module Replacement 
t/chlld relationship exists between H 
Ich contain XREFs* To denote this 

of the parent ^ deck is assigned as 
the child P or V deck. Thus* any 

the child deck results In the 
he parent deck by interrogating the 
he child deck, likewise* all decks 

deck can be generated through use of 
ECKS Criteria File directive. The 
a fl class deck Is the same as that 
IE* lOENTf PROGRAH* etc. statenients. 



CYBER 180 Systew Intsfface Staiidar^ 



4-6 
84/07/27 
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4«1,1,5 Hasilng Gyldellr^es 



If a H deck co!itains code which is later Sound into a 
ModyJe of a different name via ttie SIND.HQDUiE subcop^and 
of CRiOi> then the naras of this Bound Hodyle is assigned 
as a GROUP attribute of the M deck. The na?ae of a 
corresponding F deck nhich contains specific CREOL 
directives associated Mltti the binding of this rsodute is 
specified as a SROU? attribute of this H deck, 

F class decks contain source data which Is retained as a 
filet or contains processor directives for the processor 
nan^ed by the processor field. These decks contain* or 
=^CQPY decks containlngf information necessary for 
establishing pro grata descriptions* oaittlng entry points 
frop Sound Nodules* or establishing SCt procedure 
libraries. A typical F deck wight contain CQilECT.TEXT 
and AOD.HODIJIE commands* and *COPY»s to procedure decks (P 
decks) which contain the source of procedures to be added 
to a procedure library. Another use of F decks Is as a 
container for directives to the Real Hemory Builder or 
Virtual fiawory linker In which segment attributes are 
defined. If a SCL procedure Is to be executed from a file 
rather than a procedure library* then the processor type 
of the f deck Is SCL rtther than CREQi. The name 
associated with F decks Is the najie of this file as It Is 
accessed when the processor is Invoked* or the nawe of the 
resultant file which Is to be created. 

**Hon-cOJipi labie*' Deck Names (C* E* I* K* P* S* T* V) 

A •'non-compilable" deck Is one with the SCU deck EXPAND 
attribute value of FALSE. This type of a deck Is *COPYed 
by '♦coiapl lable** decks and assuaies any attributes 
associated with the tCOPYing deck. 

K class decks contain KEYPQINT* KEYWORD* or statistic 
codes. These codes are defined In terias of a constant 
plus relative offset* and define a set of related data. 
K decks are given a conglomerate naroe which Indicates the 
type of data being described (KEYPOINT* statistic* or 
KEYyORO). 

C class decks contain Constants. Constants are used to 
impose an upper lltult on ranges* and provide a starting 
point fros^ which relative offsets are computed. A 
constant is global in nature by virtue of Its appearance 
in a C deck. Those constants which define product 
restrictions due to their design (eg. OSCSHAX.NAHE.SIZE) * 
and those constants which represent Installation options 
are the two categories of constants with packaging 
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s and Exception conditions 
ondit ions are typically 
plus a relative offset* 
declaration to appear 
given a congi onierate name 
may be either fixed or 
a type is defined In terms 
need ordinal type) then 
ne4 in the T deck* T 
prNary type defined In 
rds then the naoie of the 
ef ined In the deck. 



P class decks contain code procedures. The content of 
such decks Is the source of non-XOCi*d procedures* SCI 
procedure definitions* or XREF declarations for XDCL'd 
procedyrss. A SCI procedure definition will contain a 
PRQC to PROCEND sequence if the P deck Is used to for« a 
procedure library* otherHlse the procedure will be defined 
in a F deck. Code sequences which are not bracketed by 
PRQC to PROCEND* or a corresponding sequence such as 
SUBROUTINE and END* should be contained In I (inline code) 
class decks. 

V class decks contain variable declarations* or the XREF 
to XDCt*d variables. A child/parent relationship exists 
between a V deck containing an XREF and the corresponding 
M or F deck in which the variable is XOCi'd. The name of 
the V deck Is the safiie as naiie of the variable which Is 
defined In the deck. The name of the parent H or F deck 
is assigned as a GROUP attribute of the V deck. 
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1 class decks contain inline code or docunientat I on* In 

the case of code* the Justification for such decks Is for 
perforfuance reasons where repeated code cannot be formed 
Into a PROCEDURE due to tlie expense Incurred In the 
procedure call* Otherwise, FUNCTIONS or IHTRINSICS may be 
contained In I decks* Inline text is text used for code 
documentation purposes Mh\oh pay also be called into a 
generated docu^ient sucfs as an ERS* 

S class decks contain blocks of related data such as 
static data of Cowsion Blocks* An aggregate nanse Is 

associated «ltN this collection of data unless the text 
data describes a specific entity* In such cases f the text 
data assumes the sane descriptive string as that 

associated with the entity It Is describing (eg* 

OSSSN^INFRANE.PAGEABl^.HEAP)* 

♦•Non-coiiipi I abl e" Deck Names <Df X) 

Decks belonging to this category represent packaging 
anomalies, and should be avoided swhenever possible* 

class decks contain conglomerates of Types and/or 
Constants* Since it Is difficult to ascribe meaningful 

Identity to such comb f nations, the use of the D class 
should be avoided when possible. It Is advantageous to 
define parameters for procedures in a D class deck* This 
anoiialy exists due to the nature of the constructs 
necessary to define procedure parameters* 



X class decks contain the XDCL definition of pro 
variables* The recorn^ended location for the sou 
XDCL'd procedures or variables Is within a conipi 
(H or F class)* Coinblning XDCL'd procedures int 
fpodule is a function of the CREATE. 08 JECT^tlBRAR 
copiiand SIND.HdDULE* If the XDCl'd procedure Is 
other products and/or users, then the XDCL'd nzm 
preserved as a result of Binding, otherwise the 
discarded provided there is a corresponding XRFF 
binding time* Therefore, It Is a product^s r^sp 
to CHANGE. HOOIJLE.ATTRIBUTES of the Bound Hodule 
names within Bound lor Unbound) modules which ar 
be externalized by the product* It Is recognize 
being able to combine several XDCL'd procedures 
variables into a single compilation unit can pro 
additional debug capabilities provided by a copp 
Is for debug purposes that X class decks exist* 
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4.0 SYSTEHWIOE CGNVE^TIO^: 
h*l*Z R£S£RV£D FILE NAHES 



4«1.2 RfSERVEO FILE NAMES 



Tlie following files i* It I have special uses? 

INPUT Is that portion of the primary Input fife that 

follows the Systei co^flsand statements* 

OUTPUT Is the primary output file and contains a copy of 
the job dayflle at the %r\6 when printed* 

F#r Interactive jobs# the terminal is assumed to be both 
INPUT and QilTPIJT. 



4*1,3 DATE AND TIME 



yiiile NOS/VE provides data and tlae data In several 
fomsats* products are restricted to using one format 
unless language standards dictate otherwise* The format 
to be used Is the Installation defined default format* 

For fixed position listing and file forisats* date and time 

fields must be large enou<3h to accomasodate the longest 

forms returned by the 0/S* 



4 • 2 IliI£E4CIlM£-£EQC£iaI^iS 



This section Identifies capabilities products isu 
to support users interfacing the systeis from I nt 

terml nals* 



St provide 
eract Ive 



Products suoport different levels of Interactive usage* 
Therefore a product does not necessarily support all of 
the capabilities described below* For example* products 
that typically perforpi batch functions (e*g* coraplle 
FORTRAN source) do not provide the same level of 
Interactive capability as one that typically performs an 
Interactive function (e*g, query a file). 
Hany of the capabilities are provided by the operating 
system and therefore are available to all terminal users 
independent of the prograi^/appl icat Ion being used* 

Specific Interactive capabilities to be provided by C180 
products are described below* A key Is used to Indicate 
which products must Include design and I mpl ementatlon of 
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4.«2 IMTERACTIVE PROCESSIt^G 



tl^€ capabi II 1 1 f s • TN« keys are? 

4 - It Is the responsibility of all products to support 
the capabilities warked with ttie A key.» 

- This key notes the terminal capabilities supported In 

the ifnpl enientat Ion of the operating system. These are 
available with all Interactive usage and are provided 
byj 

« Job Hanagewent 

• Hessage Generator 

« File Royt Ing 

m Basic Access Method 

. Transaction Executive 

. Network/CoMun Icatlons Access Hethod 

1 - This key notes the terminal capabilities supported by 

'•Interactive prodycts**. These prcgrasRs norjaally carry 
on a dialogue witl? a teriiinal user to obtain feedback 
and dynamically direct processing* They Includei 



Job ?^anagement 

Message Generator 

El le tout Ing 

HELP Util Ity 

Transaction Executive 

BASIC 

API 

OS UtII I ties 

Query/Update 

Report Writer 

FHU 

Interactive Debuggers 

SORT/HERGE 

scu 

Ed I tors 

Conversion Utilities 



4. 2,1 INTERACTIVE OUTPUT 



4.2.1.1 ££0££ai 



a) The page width and length at an output device varies 
not only by device type> but also by the size of paper 
being used In the device. The user must be able to 
indicate the operational page width and page length of 



4-11 

CYBER 18§ Systea Interface Staridard 

84/C7/27 
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4, 2 #1.1 General 



tlia output cfavice* Defaults that correspond to ttie 
terinlnat characteristics are supported. 

b) lines of data tiiat exceed the output device page width 
must be delivered without loss of data* Data that 
Niould be output be^^ond the right side of the page must 
be folded onto a second or successive line C reference 

sect ion 3»3«1«§) • 



c) The user must be able to have every output line 
formatted so as not to exceed the output device page 
width provided the output device page width Is not 
less than 72 characters* As a minlmumf the user roust 
be able to specify that output be formatted for page 
widths of 72 or 132 print positions (reference 
section 3. 3*1*4)* 

-0- 

d) Any output that «!iay go to an ASCII sequential file way 

Instead go to a terffllnal* 



e) Any output aiay contain a carriage control character 
(reference section 3*3*1*3) « 



f) The carriage control character will direct printing of 
an output file and will not appear In the print output* 



4*2*1*2 !2fis&aiJ£S 



a) Hessages must be courteous* Words such as "Illegal" 
should be avoided In favor of words like "Incorrect" 
or "unknown"* Error messages must* where appropriate^ 
suggest what the user ought to do to correct the error* 

-A- 



fo) Messages must be formatted for narrow listings* 
-A- 

c) Messages must be iseanlngful such that an Inexperienced 
or casual user Is able to understand the message and 
respond appropriately without reference to a manual* 



-A- 
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4#2.«1.2 Hess ages 

d) kny (iisssaga longer than 20 characters must have an 
altsrnata brief coynterpart* 

e) A user must be able to select either a brief or long 
forip of a message* When using the brief form of 
ffiessage# the ysar should be able to request that the 

last message be repeated In Its long fori* 
-0- 

f) Hessages soliciting Input (prompts) should always be 
used to Indicate that the user is expected to supply 
Input* 

-I- 

g) Prompts should appear on the saiwe line as the Input 
whenever physically possible* 

-I- 



4.2*1*3 Listiasa 

a) Pages of output that are longer than the output device 
page length must be delivered without loss of data* 
Data that exceeds the page length must be continued 
onto a second or successive page* 



bl 




rite any 
a Malt 



c) The user should be able to have heading information 
repeated om the second and successive terminal pages 
of a listing* i^hen display space Is lljwlted and the 
information band **idth is low* the user might choose 
to not use space to display repetitive headings and be 
able to see more data* ^here the listing consists of 
many columns that are hard to differentiate* the user 
might choose to have headings repeated on every page* 
This capability requires that? 1) Page Header text be 
Identified so it can be discarded* and 2) Title text 
be identified so It can be replicated* 

-I- 

d) When initiating a function the user must be able to 
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4«2«1»3 Listings 

select alternate awoynts of detail to be Included In 
tha listing. By selecting less detail* the user ought 

to be able to have ^ore I tens displayed on eacti page^ 
and not Just get less information per page. 

-A- 



4.2,2 INTERACTIVE INPUT 

These standards supplepent section 2«3» 
4.2.2.1 SSEStJi 



a) User discovered typing errors frrust be correctable by 

backspacing and retyping. 



b) The user must be able to cancel the Input line being 
typed at any point before input completion is 
Indicated. 

c) No extraneous blanks will fee appended to the end of 
the user defined input data for padding* Application 
of this rule Is only re<iulred If allowed within a 
product's standard. 



d) No user typed trailing blanks will be deleted from the 
Input data. The application of this rule Is only 
required If allowed within a product's standards* 
-A- 

e> Any input that may corse from an ASCII sequential file 
lay Instead be supplied by a terminal connected as 
that file. 

-A- 

f) A single Input may consist of iiore than one line* A 
prompt lay allow multiple lines of input in response % 
An input collection mode may be linpleinented In this 
nsanner * 

-0- 

g) Operations requiring only a few parameters should not 
require more than a single input* The user may enter 
all paraiueters for a directive or all directives for a 
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single systep level cowraanc^ as a single Input in order 
to reduce the nunber of interactions ^f\4 the time to 

cofppleta the directive or cop»and» 



h) The user must be able to use ti-ie standard 

atsbrey lati ons for coranand names* directives and 
paraaeter Identifiers In order to redyce typing* 



1) After Input of a command or directive has tseen 

cofflpletedf Incopaplete Input should not be treated a 
an efr<iT$ but sliould cause further prompt I ng for th 

iiilssin.g par afseter s« 



as 
e 



4. 2 •2*2 lafiut-Maaafista 



a) 



c) 



d) 



Errors in Input will be diagnosed Ifamedlately 

following the offending Input line« 
-I- 

Diagnosed input errors must be correctable without 

**exltlng" the dialogue i*lth the program* 

-I- 



"ifi^re possible allow diagnosed Input errors to 
corrected silthout re-entering the entire ilne* 

-I- 



be 




4.2.3 CONTROL 
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4 •2*3.1 CaaasiitiMiti 

a) The ys«r must bt able to have his terminal connected 
as an ASCII sequential input file and an ASCII 
sequential oytput file for any program* 

-A- 

b) The yser must be able to suppress the verification 
listing of Input when the Input source and the output 
destination are both the terminal* 

-A- 

c) Products that allow Input directives from a file other 
than INPUT nust alio** the user to have Input 
directives froi a source other than the terminal 
listed for verification at the tarmlnal* 

-A- 

d) Products that alio** input directives from a flie other 
than INPUT must allow the user to have input 
directives froi a source other than the terwinal 
diagnosed to the teriiiinal* 

-A- 

e) The user should be able to logically disconnect the 
terminal from an executing program without causing the 
program to be suspended* The prograju should continue 
execution and the user should be able to 

simultaneously enter other coiiuiands (Including 
execution of other programs)* 



4*2*3*^ iGis££M£i&.aail-Cana£atiiiC-aL£ilis 



a) The user lust have a method for gaining control over a 
prograw In execution* This Is known as an Interrupt* 

-0- 

b) An Interrupted program will not be aborted as a result 
of the Interrupt* 



c) For a program written to execute in an interactive 
environrnent* an Interrupt must cause the program to 
enter a known state* This state will normally be one 
that solicits directives or commands frojs the terminal* 
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4#2«3»2 Ir^terrypts afid Cennectlon Breaks 



-I- 

dl For a progr'aii written to execute in a -batch 

envlr ori?iisnt# an Intarrupt fpust cause the program to be 
susper^ded in such a iianner as to foe r est ar table during 
the sa«8 tarnilnal session* Control Is returned to the 
coffliTiand language interpreter* 



e) k connection break Is often caused by a co!i?fnunl cat Ion 
line failure* k connection break ^ust not cause the 
teriiinal session to be atoortedf but liust cause It to 
be suspended In such a isanner as to be restartable 
Mhen the terfitlnal user can again get connected* 

f) A user ^nust be able to restart a suspended program* 

-0- 

g) 4 user «ust be able to terflilnate a suspended prograii 
without first restarting It* 



h) A prograniJ written to execute In an Interactive 

envlroniient must accept a ternilnatlon directive In the 
state entered as a result of an Interrupt* This 
directive must fee the saise as the corresponding system 
command to terminate a suspended program* 
-I- 

i) Any incomplete terminal input request froifl a progrars 
that is suspended should be reissued (with the proper 
prompt) whan the program* Is restarted* 
-I- 

j) The temlnal user ?Bust be able to interrupt the output 
being delivered to the terfplnal and cause the 
rensalndar of the output to not be delivered to the 
terminal until the next prompt. 

-0- 



4.2*3*3 status 



a) The terminal user must be able to solicit a report to 
determine the process of a program* without causing a 
chanjja In the state of the program. 

-0- 
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4.11 SYSTEHWIOE CQH^ENTIONS 
4 •2.3 .3 Status 



) Progress reports must Indicate the functional progress 

of the progr'aii.' For exanipleJ 



''conplHng program SAM*..^ 
♦»cojspiling subroutine TOH..«»» 
♦•preparing global cross-reference. ♦ ♦" 

c) The terminal user must be able to solicit a report to 
deter^Jine the systeot environment within which a 
program Is running without causing a change In the 
state Qf the program. An Installation option to 
disable this nust be provided* 



The sfstei environment report roust indicate (possibly 
Indirectly) the response time the terminal user can 
expect to experience. This pight be by Indicating the 
length of swap-out queues* the number of interactive 
usersf etc. An Installation option to disable this 
must be provided. 



e) The terfitlnal user roust be able to solicit a report of 
the state of Its program without causing a change In 
the program's state. An Installation option to 
disable this must be provided. 

-0- 

f) The prograsi state report liust Indicate the rate at 
which the user's program Is progressing relative to 
real tl?i?e# and the impedlruent to progress. For 

ex amp I e? 

«.i4s23Jl3 - 2.54 CP seconds Snapped Out'* 
".14524:40 - 5.72 CP seconds Running" 

•*. 14:27:10 - S.21 CP seconds Finished" 

Possible states should recognize the points of delay 
in the system; these night be Paging* Swap-out# 
Waiting for" terminal input* etc* 



g) The tertnlnal user 0?ust be able to define ternilnal 
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4.0 SYSTEMWIOE COHVEMTIONS 
4.2.3.3 Status 



attrlbutis to be associated with an inter active 
session (e.g.* backspace character f eclio laode* screen 
size). The teminaf yser fiiust be able to display the 
terminal attributes currently In effect for a teraalnal. 

-0- 



4.Z.3.4 aslE 



The temlnal user should always be able to get a 
reasonable response to the Input HELP. The response 
should Identify the user's alternatives and possible 
correct Inaut. As a directive^ HELP should Indicate 
what directives are able to be used at that point. 
The user should be able to proceed after the response 
to a HELP Input as If the Interaction had never taken 
Pl ace. 



4.2.4 PRODUCT SET RUM TIHE CQHMANDS 



4.2.4.1 £ iyS£.aail-kIOa-LilsLal 



PAUSE n (In FORTRAN) and STOP literal (in CQ80L) are very 
siiillar. They should be processed In the same way. 

a. The message PAUSE text will be displayed on the 
operator's terminal or console. Text is n or literals 
and is a laxlfsusn size of 58 characters. For batch 
Jobs> the operator is the primary systeju operator. An 
OFPSSeNO TO OPERATOR with an OPERATOR ID of 'SYSTEH 
OPERATOR* is executed to send the message. For 
Interactive Jobs* an AHPSPUT NEXT request referencing 
the file OUTPUT Is executed to send the message. This 
will result }rt a message on the terminal. 

b. In batch, an OFPI^'FCE IVE FPOH OPERATOR with the WAIT 
parameter and the same Id as above is executed to 
suspend the Job and yait for the type in from the 
system operator. The operator will respond with a 
REPLY ACTION command. In Interactive niode* an 
AHPSGET NEXT re^quest on the file INPUT Is executed 
(this may not be legal# another connected file jaay 
have to be used). In either case, the data Is thrown 
away and the Job Is continued. 
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4.0 SYSTEHMIOE CONVENTIONS 
4.2.4.1 PAUSE arsd STOP literal 



^.2.4.2 ^aQ££I«£E£ia-CQMS3LI 



The ACCEPT FROH CONSOLE CIn COBOL) should fee processed \n 
exactly the saie way as STOP literal <4«2«4»1J« Text 
^ouid be the data from a previously executed DISPLAY UPON 
CONSOLE MITH NO ADVANCING or the message 'ENTER COBOL 
INPUT VIA REPLY ACTION* If there v«as no DISPLAY. 
Interaction Is with the system operator only. Clf 
messages sent via OFP$SENO TO OPERATOR also appeared on 
the ternlnalf It could cause confusion for the ternlnal 
operator • ) 



4.3 IMSIiLUIIQM-EMMEIEEl 



NOS/VE will penis It lodi f I cat ion of all systers parameters 
dynamical I y during system execution. The term 
"Installation paraieter**# as used In the classical COC 

sense* Is not valid for NOS/VE* 

System parifneters fall Into the following general 

categories? 

. Hardware characteristics Ce.g.^ # of CPU's* type of 
CPU) 

. SysteiB and product defaults (e.g.» default tape 
dens I ty) 

• Accounting parameters 

. Limits parameters (e.g.* maximuin FL) 
. Timing Part!«eters 

System parameter defaults can be set at the following 

times? 

• Copplle tliue Ccofnpllation at CDC) 

• Build tline (da ad start tape build at user site) 

• Deadstart time Cvla operator type-In) 

These parameters isay be tested dynamically and action 
taken accordingly. The product set will require no 
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4*0 SYSTEHyiDE CONVENTIONS 
4,3 INSTALLATION P4R4HETERS 



parafi58ter spec If lat I on» and will dynaiilcaily test system 
parameters during execution via requests to NOS/VE* 

Tiia folTQwImg table Indicates the permitted range of 
systei para?net8r control for the product set and operating 
systeni* An X Indicates tNat tiie option Is allowedf and a 
blank entry Indicates that the option is not alloMed* Any 

eicceptlon reust have the explicit approval of AD£C* 
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>++- 



4.3.1 GENERAL GUIDELINES 



As a general rule* the number of system parameters shoul 
be kept to an absolute i^lnlmum. This mI It ffilnlmlze the 
additional testing Imposed by these options and will 
reduce the nuiber of ''different" versions in the field. 

A firra requlrenuent on both the operating system and the 
product sat Is that no r acojupi lat Ion at a user site will 
ever be required to Install the soft><are» This Is a 
requirement of binary release* 
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4,0 SYSTiHyiOE CONVENTIONS 

4«3*2 LIST OF PRODtiCT SET PARAHETERS 



4,3.2 LIST OF FRQDyCT S^l PARAMETERS 



The foHovijng system parameters tuay be tested dynaialcally 
by the product set via requests to HQS/Vg Clnclydlng 
networkirji) J 

type of CPU 
OS name and version 
line widtf^ or screen width 
terminal type 

screen langtli or page length 
print lines !lpit 
4.4 £iSQE.£gQj;£SSIM£ 



The purpose of this section is to describe the conventions 
and responsibilities of processing different error 
condi t Ions, 



4.4,1 STATUS VARIABLE 



All coJBuand and procedure Interfaces to the systen? that 
are visible to the end user ^ust have a status variable as 
a parameter. The status variable Is used to convey the 
result of the command or procedure and# In case of error* 
provide Information explaining what went wrong* 

For commandsf the status parajieter should always be 
optional. When It Is quoted by a user# the assumption Is 
that the variable will be tested subsequently In the 
command stream and some appropriate action taken. 
Therefore* the conditions returned to the user should only 
convey Inforinatlon the user Is likely to understand* 

For procedures* the status parameter Is required* Again 
the conditions returned should be ^% understandable to the 
user as possible. This Is particularly Important when 
there are niultlple procedure calls made within our 
software as the result of a single call by a user 
procedure, Eijiphasis should be placed on improving the 
status returned to the user rather than blindly passing 
back obscure status from the depths of the systeffl* 



Detailed formats of the 
the HOS/VE ERS. 



status variable are available in 
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4*4.1 STATUS VARIABLE 



4«4*2 ERROR TERMINATION 



There are a nufiber of errors that can occur In a products 
some of which can be detect eti and some of which can*t. 

This sectior^ daals Hlth the processing to he performed 
when detectable errors occur* 

First of alf# the product should try to detect as many 
errors ^s gracefuHy as possible* This aeans that 
Ir^ternai software tests should be used to detect ermrs as 
Mell as us log the condition handling facilities of the 
operating system to receive control In the event of a 
system or hardi^are detected error* The product cannot 
sliiply rel^ on tfie standard operating system abort 
processing. 

When an error Is detected^ the product should provide as 
fiiuch of the following error localization Information as 
possible* Some of the Inforiaatlon will not be applicable 
to a 1 1 products* 

» Type of error termination Istandard system messages 
should be used for this niessage)* 

. Full traceback of the call sequence to the procedure 
contalrVIng the error. This will be by procedure nama 
and line number or relative address depending upon the 
ajiiount of tr aceback/debug information released with 

the product. 

• Inforisatlon regarding the user data being processed* 
For a co???pller# this might be the procedure name and 
line number currently being processed. For a utility 
or data suanageinen t product* It might be the current 
record* 

« Optional dumps of useful internal tables* 

The above Information should only be logged for error 
terminations that are probably caused by product failure* 
It should not be logged for conditions such as time limit 
or operator drop which are clearly not product errors* 
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4*0 SYSTEMMIDE CONVEHTIOflS 

4.4.3 INTERACTIVE Emm PROCESSING 



4.4.3 INTERACTIVE ERROR PROCESSING 



This section supplements section 4*2# "Interactive 
Processing*** 



In considering this 
between error nessag 
difficult to daflna 

nonetl^eless. kn err 
commands In an Inter 
displayed at the ter 
happened. Olagnostl 
wliole Ce«g«9 listabl 
only want to be seia 
An example Is a coup 
message tel 1 ing how 
cofflpiiation and prod 
error • 



topic It Is necessary to distinguish 
es and diagnostics. These terms are 
precisely byt are Intyltlvely distinct 
or Rsessage Is generally a suiawary of a 
active envlronroent It Mants to be 
pinai so the user can find out what 
cs are generally a part of a larger 
e output) which due to their volujue 
ctlveiy displayed* 
iler which provides a single error 
If! any errors occurred during 
luces a diagnostic for each compilation 



4.4.3.1 Ectar.Hs&aaasa 



a* All error messages should be issued via the standard 

message generator* The message generator will 
detemine whether the message should go to the 
terminal or the log* etc* 

fo. Messages liust be courteous. People tend to react In a 
pore emotional fashion when using a computer 
Interactively than when using It in a batch mode* 
yords such as "illegal" should be avoided In favor of 
words like "Incorrect" or "unknown"* Error messages 
should explain to the users what they did wrong and* 
if possible* how to correct It* 

c. Messages must be ueaningful such that an Inexperienced 
or casual user Is able to understand the messages and 
respond appropriately without reference to a manual* 

dm Any message longer than twenty characters must have an 
alternate brief counterpart. The user must be able to 
select either the brief or the long form of the 

message* 
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4.4»3»2 Olagi^ostlcs 



4«4»3*2 OillQ^atii*^ 



a) Points b and c# above also apply to diagnostics* 
Diagnostics shoyld explain the problem} from the user's 
perspective rather than the program's. For exarapie? 

*'Cofflma Hissing after third parameter" 

Instead of 
"OVPP^RSEPR detected illegal syntax". 

b) yhlle diagnostics btb not typically displayed at a 
terminal by default/ they are looked at by Interactive 
users. This pust be considered iihen defining the 
location of the diagnostics In the iistlndt 
identifying the diagnostics with a mzTk that Is 
uni<iuely detectable nith a text editor* etc. 



4. 4 .a, 3 lQ£ut«aiaaaflsis 



This section applies to all input that can reasonably be 
expected to co?^e from a terpiinal Ce«g«f comiflfsand utility 
subcommands) • 

a* Errors in Input will be diagnosed Imiiediately 
following the Incorrect Input. 

b. Diagnosed input errors ntust be correctable without 
exiting the dialogue Mlth the program. 

c« Diagnosed Input errors may be corrected without 
reentering the entire line. 

d« Any Input diagnosed to the terminal roust be 

correctable by tern^lnai input immediately following 
the diagnostic whether or not the original input was 
f r ofn the ter mi nal • 



4.4.4 BATCH ERROR PROCESSING 
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4.4.4.1 £££||£«i£SSaJlS 

Batcti error messages should follow exactly the sawe 
guidellnas as Intaractlva particularly the usage of tt^e 
• niessage generator. 

4.4.4.2 lEtMt-fiiiaaasis 

The kind of user Interaction that Is desirable In 
Interactive node Is of coyrse Inappropriate In hatch 
mode. Eiiphasls should be placed on detecting as naany real 
errors as possible even after a fatal error has occurred. 
The key word here Is *'real"j producing a large nynnber of 
extraneous error n^essages or diagnostics i^lll ultli^ately 
lead to people only correcting one pr obleis at a tlwe. 

4«4,f TRAHS^CTIQN Emm. PROCESSING 



This sectio?^ will be added when ?sore design on the 
transaction facility has occurred. 

4.4.6 RESTART 



This section will be added s^hen more design on the system 
restart capabilities has occurred. 



4 . 5 £££££IIi£.yi£.0£-£ISa-tiAEQMM£ 



4.5.1 HAROW'ARE OPERATION 

This section describes software conventions which isust be 
followed for the hardware to function In a predictable 
in a n n e r . 
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4.0 SySTEMWIDE CONVENTIONS 
4.5.1.1 InterIocl< Words 

Contentions Locate all Interlock Mords In cache bypass 

segments* 

Special system Instructions are provided In the CPU and 
the IQU to Interlock wyltlple processors/ IOU« In general* 
these function by exchanging the contents of a register 
and a word In lefiory* Following this exchange the 
register may ha Investigated to detenslne whether tl^e lock 
has been set* For exaaiple* a zero word In memory can be 
selected to lean ''no locl<*»» then by exchanging a non-zero 
register the locl« wll I have been set If a zero value Is 
returned* It Is Imperative that such Interlock words be 
unique* To guarantee this they are placed In cache bypass 
segments* Notice that the Instructions which are designed 
to test and set locks automatically bypass cache* 
Problejns arise when the interlock words are accessed by 
other Instructions such as loads* 

4*5*1*2 £££=£££iali2atiaa-a£-.Ci^l£-.Lfl£!l 

Convention? Before clearing a single bit lock Cvia a Store 
Bit Instruction) first sQt the lock by a Test 
and Set 8 It Instruction* 
Care must be taken whenever an Interlock word Is set or 
cleared to pre-s eri al Ize the operation* This Is done to 
ensure that* In the event that raejiory references are being 
satisfied out of se<?uence# all outstanding ineiiiory 
references are cojipleted before changing the lock* In 
practice* CY8ER ISO systems designed to date always 
satisfy neraory references in sequence* However* this way 
not always be the case* The Instruction which sets a 
single bit lock (Test and Set 8 It) performs the necessary 
pre-ser i al I zati on. However* to clear the lock a Store Bit 
(with a zero operand) niust be used* Since this 
instruction has a general utility It does not 
pre-ser I al Ize* To compensate* the Test and Set Bit 
instruction post-serializes* Hence* to ensure a 
pre-ser la I Izat I on of the clear lock* the lock should first 
be sat (with a Test and Set Bit Instruction)* then cleared 
by the next instruction* 
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4,0 SYSTEMMIDE CQt^VENTIONS 
4.5«1«3 Register ^esarvatl orss 

Convent lanr Regi sters A0-A4 and XO-Xl shall be reserved 
for special functions. 

The CY8ER ISO Instryctions wake us« of certain registers 
to tiold given values* The assignments atb as foilo*»sJ 

AO - Oi^nailc Space Pointer (DSP) 
hi - Current Stack Fraiie Pointer ICSF) 
A2 - Previous Save Area Pointer (PFA) 
A3 - Binding Section Pointer (8SP) 
A4 - Arguiiant List Pointer (ALP) 

These registers hold tfiose values by software convention* 
but a convention i^hlch Is supported by the hardware* 
Hence* It Is very liioortant that they be supported by ail 
soft^iare procedures* In particular* Al and AE must never 
be altered by Instructions other than Call* Return and Pop* 

In addition to the reservations above* registers XO and XI 
have a special meaning In the hardware. For lany 
Instructions* the XO designator Is used to Indicate no 
register* Hence* register XO cannot be used by these 
Instruct Ions* Both XO and XI are used as fixed utility 
registers for several Instructions* Examples are? 

1) Load/Store multiple and CALL instructions use XO 
for 3 save area descriptor* 

2) All compare Instructions return a value to 
Xl-Rjght* as does the Hark to Boolean Instruction* 

3) The BDP Instructions optionally use XO-Rlght and 
XI~Rlght to hold operand lengths* 

Since these registers are used for special purposes* care 
must be exercised if they are used In a general manner* 



4.5*1.4 Aiiafiffifiat-a£-Ialiiaa-aQd-Hfl£jis 



Conventions Align certain tables and words on specified 
boundar i es* 

Although CYBER 180 is nominally a byte addressable 
machine* real lemory Is organized Into 64-bit words* 
Consequently* the performance of certain operations has 
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4.0 SYSTinyiOE CQNVENTIO^IS 

4»5#1»4 Alignisent of Tables and Words 

been opt in? I zed by placing the operands on word 
boundaries* The complete set of data allgnisents necessary 
Is given below* along with a brief description of Mhy tbe 

ailgnment is required and what **MI tsappen Mtien the data 
Is not aligned correctly* 

4*5,1«4,1 64-8IT WORD BQIINOARIES 

The followNg data either must be» or should be aligned on 

word boundaries? 

1) Process Segment Table - For performance reasons the 

hardfeiare Indexes Into the 
segi!5ent table at a word 
boundary. The virtual memory 
address translation mechanism 
will fall If the segment 
table is incorrectly aligned. 

2) Binding Sections - To liaxiflilze the reach into 

the Binding Section by the 
Call Indirect instructlonj 
access Is made to a word 
boundary* If the Binding 
Section Is Incorrectly 
aligned^ then an Address 
Specification Error results 
when a Call Indirect Is 
Issued* 

3) Procedure Entry Points - To maxifBize the reach of the 

Call Relative instruct I on j a 
branch is fnade to a word 
boundary* Since the 
instruction forces the 
address to a word address* 
results will be unpredictable 
If the procedure target was 
not correctly aligned* Note 
that even though It Is not 
strictly necessary for 
procedures called via a 
Binding Section to be word 
alignedf difficulties could 
still result if they are 
not* This Is because the 
CYSeR 180 Library Generator* 
in the process of "binding** 
may convert Call Indirect 



CY8ER 180 System Iriterface Standard 



4-29 



4,0 SYSTEMyiDE CQH¥E^TIOHS 

4.5.1.4.1 64-BIT mm BmmMiEs 



Instryctions to Call 
lostructions. 



Rel atl ve 



4) Debug List Entries 



) I o tar lock ^ords 



6) Stack Fraiss 



7) Central Heiuory Data 

Accessed by the lOU 



- To simplify the hardMare* and 
to optimize per fori?? ance nhen 
In debu9 fliode# the hardware 
accesses debug list entries 
on word boundaries. 
Incorrect allgnsaent will 
cause unpredictable results* 

- Interlock words used In 
conjunction with the 
Compare/Swap operation roust 
be at igned on a word 
boundary* This Is necessary 
for the processor to satisfy 
the non-preeniptl ve 
requirements of the 
instruction. Processors 
utilize the 64-blt meiiory 
exchange function in this 
operation. That function 
operates on a real mefflory 
word. Incorrect aiignaient 
will yield an kMress 
Specification £rror. 

- By software convention only» 
stack frames should be 
aligned on word boundaries. 
This enables the hardware to 
load and store the registers 
held in the save area from 
data on word boundaries. 
Incorrect alignR?ent will not 
cause any problems since the 
hardware always adjusts 
(forces) the Dynamic Space 
Pointer to a word boundary 
before accessing a stack 
frame. 

- The lOU can only reference 
central memory words. Hence* 
it would require some special 
code in PP's to decode data 
not stored on word 
boundaries. This is really a 
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4,§ SySTEHyiOE COHVENTIOHS 
4,5.1,4.1 64-BIT HORO BOUNDARIES 



pragmatic software convef^tlan 
since a ?? tits no way to 
specify a cantral memory 
address other than on a word 
boundary* 



4*5*1*4*^ OTHER BOUNDARIES 



The following data liust be aligned on boundaries other 
than 64-blt word or 8-blt byte. 

(II Exchange Packages - 128-bit C2 word) Boundaries 

To optimize the performance of the exchange jurop on some 
processors^ the hardware addresses two words at one tl«e« 
Results will be unpredictable If the exchange package Is 
incorrectly aligned* 

(2) Instructions - Parcel <2-byte) Boundaries 

Instructions* which bt^ either 16-bit or 32-blt 
quantities^ ?iiust be aligned on parcel boundaries* 
Failures to do this will either result In unpredictable 
behavior^ or an Address Specification will be detected. 

C3) Page Table - Page Table Length Boundary 
To ffliniffllze the tlia needed to translate addresses from 
virtual to real> the hardware catenates (rather than adds) 
the Page Table Addresses (PTA) to the page table Index* 
For the catenation to yield the correct address* the 
low-order bits of the PTAf as determined by the page table 
lengthf riust be zero* Failure to structure the PTA In 
this manner will cause the address translate mechanism to 
fal 1* 



4*5.2 HARDWAtS PERFORMANCE 



Whereas the previous section dealt with conventions 
necessary to make the hardware work correctly* this 
section deals with conventions necessary to make the 
hardware work efficiently. As such they are not 
mandatory* and In some cases represent merely suggestions 
as to how to optimize certain functions* 
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4,0 SYSTEMMIDE CONVENTION; 



4.5«E.l Lfl£iiiti_fif.Efi£tLaii££ 



Convent Ion J Place all code and all data to be used at one 
time In one place* and keep to a mlnlniym the nuraber of 
segments rec^ulred to execute a given task* 

The CYBER 180 virtual memory organisation provides tNe 
basis for the system security and sliplifles the explicit 
organization of a prograji Into overlays* However* all 
programmers have responsibilities If systei throughput is 
to be optiJilzed. A prlipe responsibility Is to Maintain a 
strict locality of reference* That is collect all code 
and all data that Is to be used at one time into 
contiguous pages In one segment (each for code and data)* 
This has two advantages* it rainiJBizes the working set Cthe 
nuisber of pages allocated In real weiory at any given 
point of tipelf and it also rolnijulzes the nu«ber of 
entries which lust be made In the buffer memor Ibs* By 
minimizing the viorkSng set the number of concurrent tasks 
vfhich can be held In real iReroory Is aaxlfilzed* This* in 
turn* fnaximizes syste® throughput* 

OptiiPizIng around the buffer meinories represent a slightly 
different problens. These have a finite size and contain 
the most recently used Segment Descriptor Entries and Page 
Table Entries. If a large number of segments are In use 
at one tlfpe* or If a large number of pages are in use at 
one tisjej then the buffer meiiories will be unable to hold 
all the necessary entries and they will be constantly 
loading new values* The affect will be similar to not 
having theiTi at all and performance will degrade 
cons iderab ly • 

Consequently* not only should pr ogr anfiraers maintain a 
locality of reference* but they should also try to 
localize the number of segments used by a given task* 



4*5.2.2 Esjisi£i:-4iiiiaatiQQ-aa!l-.ysia£ 



Convention: Allocate A-Reglsters and X-Reglsters from the 
small numbers on up* 



As a result of the special functions for which A0-A4 and 
XO-Xl are used* and the method of saving/restoring 
contiguous registers by the CALL/RETURN Instructions* 
register usage should always start with the smallest 
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possible oymfoer {typically A5 and X2)« This will help to 

ffllniJilze t:ht nueiber of registers which Jiust be saved 
across procedure calls* Thls# In turnf will optliiize 
perforia^nce in this area. 



4.5.3 SECURITY 



This section lists software conventions needed to provide 
a secure environnient at ail tiRies. Since a major 
objective of the CYBER 180 progran is to provide i highly 
secure systefi# these conventions become mandatory* These 
conventions are closely related to those in Section 2. 
Just as they are re<3u I red to inake the hardware operate in 
a correct* predictable manner* so are these required to 
guarantee that the security and protection algorithms 
function correctly. 



4.5.3.1 £La£SilU£^^E^£.IlSttL& 



Convention! 1) 



Always use caller's argufpent 
for accessing caller's data. 



I ist pointers 



These 
f r JTi 
When a 
execut 
respon 
execut 
P r V I d 
ensure 
br acke 
may th 
by c a I 
held i 



conv 
ne p 
pro 
es 
s i b I 
e wi 
es t 
s th 
t# a 
en a 
I er . 
n A- 



2) Always load pointer parameters directly 
Into A-Registers - via load A instructions* 

3) Whenever possible avoid moving record 
structures that contain pointers* 

4) Avoid passing pointers between rings 
either way. 

!?) Avoid data structures containing direct 
pointers that cross rings either way* 

entions are mandatory for those procedure calls 
rocelure ta a second one with more privilege* 
cedure Is called by another procedure* It 
n behalf of the caller. It is the 
lity of the cat lee to ensure that it does not 
th fJiore privilege than caller* The hardware 
he basic security mechanises* In this case* it 
at callee Is called from within Its call ring 
nd that it is called via a Binding Section* It 
ccass code and data belonging to or accessible 

This code and data Is referenced via pointers 
Registers* and the hardware performs a ring 
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nymbsr vote whenever an A-Register Is loaded^ This 
wechanisffl ensures the least privilege {highest ring 
number) Is alv^ays accorded the user* Howeverf there are 
fiisny ways this fiechanlsm can be be-passed* The simplest 
fsethod is for callea to load a pointer into an X-Register* 
then copy It to an A-Registsr* If caller places a low 
ring nuaiber Czaro would do) In the pointer* then it wlil 
end up with cal lee's ring nuB^ber In the A-Register* That 
IS it will end up with more privilege than that to which 
caller Is entitled. It Is ca I lee's responsibility to 
ensure this doas not liappen. The onus for tsalntalning 
security always fal Is on the wore privileged procedure* 
Hence* the convention. 



4.6 M££aEI.0£-.£aailia.a4I4 



EBCDIC data can he divided Into two distinct classes! 

1. all 8-bit character data (also known as coded data* 
Including unpacked nymerlc data types); and 

3* Intersilited character and non-character data. 

Support for the former (all character) Is provided by the 
operating systain. If EBCDIC is specified on the request 
cardf the tape driver automat I ca 1 1 y translates to ASCII 
when reading the tape and translates back to EBCDIC when 
writing the tape. 

Support for the latter C Intermixed character and 
non-char acter) # and for the EBCDIC collating sequence* 
varies by products 



EBCDIC SUPPORT 
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c 
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8 




Intermixed EBCDIC Input file e 
Intermixed FBCDIC output file e 
EBCDIC collating sequence X 



X 

X 

X X 
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X » support reqyl red at Rl of product 
e « evsntyal support desirable 

Support of Intermixed input and output files weans use of 
tlie special CIBO Instructions to process the following 
"translated*' non-character EBCDIC data types? 

• Binary (slaned ^n6 unsigned) 

« Packed Decimal (signed and unsigned) 



4,7 E£X£QIUI.yS4££ 



The CY180 keypoint facility provides a mechanism to enable 
collection of statistics for performance fuoni tor lng« A 
data reduction software package Is available to suaifsarize 
these statistics based on descriptors contained In a 
keypoint descriptor file CKDF)* This section docuiaents 
ttie conventions to be followed by the operating systeaj and 
product set in the usage of this facility. 



4.7.1 KEYPOINT CLASSES 



Five keypoint classes named ENTRYf EXIT* UNUSUAL* DEBUG/ 
and DATA are defined for the operating system and product 
set. 



ENTRY 



EXIT 



UNUSUAL 



Every gated procedure plus all major 
internal procedures (those shared across 
functional areas) should contain a 
keypoint of this class. These keypoints 
should be placed as close as possible to 
the entry to the procedure. 

Every gated procedure plus all major 
internal procedures (those shared across 
functional areas) should contain a 
keypoint of this class. These keypoints 
should be placed as close as possible to 
the exit frofR the procedure. 

Every situation which Is unexpected or 
quite unusual should contain a keypoint of 
this class. It Is Intended that these 
keypoints would be enabled at all times. 
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The freqyef^cy of encounter ing these 
ksypolnts s hoy Id be yery Iom» The DATA 
keypoint class Is not ailoiifed In 
conjunction **ith a keypoint of class 
unusual • 

DEBUG These keypoints would be for providing 

addltlonn trace Information as an assist 
In deljugging of hardware or software 
problems. 0E8U6 class keypoints would be 
post useful In the nore cotsplex areas of 
the systep* The primary use of keypoints 
In HCS and MQS/VE up to this point has 
been for debugging purposes* 

DATA This keypoint class can be used with the 
ENTRY* EXIT* and DEBUG keypoints for the 
gathering of extra data. All DATA 
keypoints encountered are supplying 
additional data which will be associated 
with the last ENTRY, EXIT or DEBUG 
keypoint* Hence, they should follow as 
closely as possible after the ENTRY, EXIT, 
or DEBUG keypolntl in particular, there 
should be no Intervening CAtl 
Instruction. DATA keypoints should be 
used with care since the PHF hardware can 
only buffer up 16 keypointsi keypolnt 
clustering can cause lost keypoints. 

Keypolnt Data ?ind Ident If I cat ion J 

Upon successful execution each keypolnt Instruction will 
provide a total of 32 bits of information. The convention 
uses 12 bits of this for keypolnt Identification and the 
remaining 20 bits as user supplied data. Try to use this 
20 bits to provide meaningful Information <taskld, segment 
number, flleld, queue length, page number, time, etc.). 
On DATA class keypoints the data belongs to the previous 
keypolnt and the full 32 bits Is available for additional 
user data. 



4.7.1.1 a£5iatla£.^:xat2i 



The keypolnt classes for NQS/VE are as followsi 
QSC$DATA=D 
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Q$C$UHUSUAl«l 
0SC$SHTRY=2 
QSC$EXIT»3 
QSC$0£SUG=4' 

Keypoint class 5 Is r^eser^ed for NOS/VE. 
4. 7. 1.2 £Ladii£t-.a£t 

The keypoint classes for the product set are as followsJ 

PSC$DATA»6 

PSC$UNUSUAL«T 
PSC$£NTRY«8 
PSC$EXIT=9 
PSCSO£ByG«lO 

4.7 a. 3 Qlll££.ailS^Sa 

The keypoint classes 11-14 are reserved for users* 
Keypoint class 15 Is reserved for PHf hardware control. 

4.7.2 KEYPOINT IDENTIFIERS 

A maximum of 49 95 keypoint Identifiers are available for 
(each) HOS/VS and tha product set. The combination of 
keypoint class and identifier Is unique within the system. 

4.7.2.1 Q2SiLgtLU2^1l^tm 

(To foe suppi led) 
4.7.2.Z ELfiiiilfit^ill 

The set of 4095 avail able identifiers is partitioned Into 
a primary range table and an overflow range table. Every 
product set mef^iber has an entry in the primary tablei the 
range size Is 50. Those product set members which require 
more than 50 will be assigned one or more entries In the 
overflow table* which also has a range size of 50. 

The primary range table is given belowx 
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Prodyct Idei^tlfler 

A.A Advanced Access Hethod 

AP API 

BC BASIC 

CB C0801 

D8 Interactive Debyg 

FC FOI?TRAN CoiipMer 

Ft Fortran Ryn-TI«e 

FH File ^lanageiient Utility 

FT FORTRAN Global 

W Information fianagewent 
Fad II ty 

PA PASCAL 

Pi PL/ I 

Oy Qyary Update 

SM Sort/Herge 

SV Stiared Variables Processor 

CCH Coii?noi Compiler Hodules 

CG Conif!3or> Code Generator 

HC Host Compi I er 

Nl Hath Library 

CY CYBIL 

SOU Source Code UtI I Ity 

At Assembler 

FA File ?1lgratlon Aids 



Primary range 






— 


49 


50 


- 


99 


100 


- 


149 


150 


- 


199 


zm 


- 


249 


250 


- 


299 


300 


.« 


349 


350 


- 


399 


400 


- 


449 


450 


- 


499 


500 


- 


549 


550 


- 


559 


600 


- 


649 


650 


- 


699 


700 


- 


749 


750 


- 


799 


800 


- 


849 


850 


- 


899 


900 


- 


949 


950 


- 


999 


xoco 


- 


1049 


1050 


- 


1099 


1100 


. 


1149 



CYBER 180 Systeii Interface Standard 



4-38 



4.0 SYSTEHMIDE CONyE^TIONS 
4.7*2*2 Product Set 



1150 - 1199 
1200 - 1249 
1250 - 1299 
13§0 - 1349 
1350 - 1399 
1400 - 1999 

Tiis overflow range extends from 2000 to 4095. 

Assignment Is based on an as-needed basis In groups of 
50 • A given product msy have lore than one asslgn?pent 
In the overflow range* 



LI 


LISP 




AD 


Ada 




FV 


COC Fortran 




VX 


VX/VE 




vc 


C cornpller 






(Reserved for 


fytyre 




products ) 





4.7.3 KEYPQINT USE 



Froffi a software point of view* keypolnts are special 
commands that are Inserted In a module according to the 
gyidellnes specified In section 4.7.1. For a module 
written In CYBIL* the iKEYPOINT Intrinsic can be used to 
generate the kaypoint Instruction (refer to CYBIL Language 
Specif lcatlon# ARH229B, and HIGDS* ARH1700# for details). 

The main entry keypoint Identifying a product set ^e^ber 
should Include data which Indicates the actual version of 
the product. This Is useful for tracking slfnul taneous 
execution of the same or different versions of a product* 



5-1 

€Y8iR 180 System Inttrfice Stao^ard 

5,0 COHPIiER AHD I^SSEHBIY CODE COH^iHTIOHS 



5 * i:0iEIL£E«4ifi«AiS£aaLI-£Q[|£-.i:01iM£liIIQiS 



Tliis standardl Is to be followed by tlie object co<^e 
generated by the coiip Iters and by any asse«bler code 
written as part of standard software. 

In addition to these standards^ assembler code 
Cbandwritten or coiapller generated! will conforfi to tbe 

coding standards described In CYBER 180 HAINTENANC£ 

SQFTyARE COOING CONVEHTIQMS <OAP ARH216Ci). 



5.1 yS£-0£-LQ4I^£E.££iiya£i 



1. The loader specification Is limited to that written In 
Its for?!?al docyinentat lon» Progr ariraiaers shall not 
depend on additional characteristics deterilned by 
empirical observation* as such behavior may be subject 
to cliange* Examples which have caused trouble on 
CY170 :^TB the presetting of undefined variables^ the 
order of loading frora a library* and the address at 
whicii the first code is loaded* 

2. Runtime routines shall not limit the program 
structures of their users. On CY170 all Cf?H 1 
routines firaust be In the root segment of a segmented 
load^ and CHH must have at least one routine In the 
iiiain overlay of an overlaid program* Such 
restrictions nust be avoided on CY180. 

3. The following table shows In which sections particular 
types of data should be allocated* and the attributes 
the section should have* 

Attributes R - read* W « write* B « Binding and 
E « execute* 

Section 
Data Type Type Att Comnient and Examples 

"Static" Working R* W All variables not 

allocated on the stack* In 
comn^on or explicitly 
allocated to a section* 
Includes FORTRAN local 
variables* CYBll CSTATIC3 
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ConstantsCl) Working 



Constants('2) Code 



and CXDCll variables. 

All literal constants 
which for reason of 
indirect addressing or 
length cannot be expressed 
directly in the code* 

Optional ly> constants as 
in ID which are less than 
8 bytes long and 
conveniently accessed 
throygh the IBYTP 
instruction. Note that 
the **constant»» «ay not be 
a PVA. 



«XREF»* 


Bl nding 


B 


Data declared in another 
unit of compilation are 
usually referenced through 
pointers placed in the 
binding section by the 
loader Crather than In 
user sections indirectly 
referenced through the 
binding section^ where 
they would be inaccessible 
to the binder). 


Heaps 


common 
ext ens- 








lb le 


?$^ 


For the systen? heap see 



section 5.4. 3« Other 
heaps are declared in 
CY8IL. 

The following action should be taken if a compiler 
detects a fatal error in the source code it Is 
compiling* unless tha compiler was called with 
«DE3UG«0C*' (see section 2.2) t 

An IDR record shall be issued containing the string 

••errors in compilation'* 

In the comment field. The non-executable attribute 

sha I I be set • 

If DE8UG»0C was selected* the compiler shall continue 
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nofiial processing as far as possible* 

All compHars sliould emit loader names {common block 
naines^ XRSF naies> isodyle names^ etc*) using upper 
case alphabetic letters wt^en letters occur In tt^e 
names* kn except Ion to tfsis rule is raade for any 
language i^hlch requires the distinction between upper 
and fo^er case names* 



S * 2 I!iIEELiM£yAE£-CiLLIMi'-S£ay£M££S 



Purpose 

The purpose of the I nter I anguage calling seciuence is to 
facilitate Intar-I angyage procedure calls* This is 
particularly desirable on CYBER 180 because of the systein 
level support for sharing of code between executing 

tasks* For exaspple* It would be desirable to have only 
one set of nsathemat I cal routines to be used by all 

I an gu ages « 

Restr I ct ions 

All CY8ER 180 Compilers roust be capable of generating the 
CYBER 180 Inter I anguage Calling Se<iuence for an externally 
refer en ceabi e code raodute* TIE I s a goal In the definition 
of this calllni sequence that It be useable by the 
majority of the compilers as a subset of their standard 
cal 1 1 ng sequen ce * It obviously cannot meet a 1 1 of the * 
needs of I an gu a Fes as diverse ss 8 ASIC and PL/ 1* It would 
be acceptable (but certainly not preferable) if a 
particular language were to require special declarations 
or attributes on a procedure call to cause the generation 
of this calling sequence. 

It Is expected that users in the various prograflimlng 
languages may have to take additional steps with respect 
to data declarations to guarantee that the alignment and 
packing correspond to that specified by this interchange 
standard* The user Is also responsible for the values 
passed via this calling sequence. For exaipple^ a Boolean 
variable light contain values 0-7 Cslnce It occupies a 
byte) but the comnion calling sequence only assures 
inter I anguage capability for the values and 1* 
In generals a compiler may employ any calling sequence it 
chooses bet^ieen Itself and Its library or non-external 
procedures* Exceptions to this villi be for routines which 
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can be of general use 
I ibrary roytinas ) # S 
sequence but lust als 
to tine inter language 



5.2.1 CALLING SEQUENCE FQR^HATS 

The Inter I anguags call! 
the layout of tfie p 
descriptors associated 
the Inter language c 
*' Inter I angyage calling 
formats collectively, 
to provide flexibility 
unreasonably clegrading 
will be referred to 
Extensions to either o 
the SIS. 
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5.2.1.1 iliQi&.si.£iLaiatti:s 



For purposes of exposition* three k 
distinguished? value parameters* si 
extended reference parameters. 

Value parameters are those parameters 
to be passed. The calling progra 
argument It passes will not be changed 
that this does not Imply a speci 
(several are possible}. 

Reference parameters are those paramet 
intended to be passed. The cal I In 



Inds of parameters will be 
mple reference parameters* and 



for which a value Is intended 

m can assume that the actual 

by the called program. Note 

fIc implementation technique 

ers for which an object is 
g program must assume that the 



J*"' 



CYSER 180 Systeii InterTace Standard 



5-5 



5,0 CQHPIiER km ASSEHBLY CODE CONVENTIONS 
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actual arguJiaent It passes may toe changed by t^e called program* 
Note that this does not imply a specific I sjp I e mentation technique* 
although at least -an address pust normally be- passed* Soie 
reference paraieters also require that certain descriptor 
information must be Passed aiong with the address* 

^ Siwple reference parameters are those reference parameters which 
require only an address* or only an address plus a string 

descrlptor<> to ba passed to the calling routine. 

Extended reference paraneters are those reference parameters i«hlch 
are composed of an address plus a string descriptor plus a 
non-string descriptor* or of an address plus a non-string 
descr I ptor . 

5 .2 •! .2 iisi^i«£ii£iai;«af «ilia-.lQiLtLiaaaMJia£.Caiiiiia-SLfiaufia££ 

This forifiat Is the one used by the system imp lementat Ion language 
<CY8IL)> and all operating system Interfaces. This forraat is 

docyaiented in detail In section 3*Z*3m"l of the SIS* 

5.2*1.3 2fifi£LJl«£aLiBit-af -l!ia«Ifit£Litiiaiiiafi.CaliiQfl>Sfiau£a££ 

This format is lore general than the system forfsat* It will be used 
by CDC FORTRAN, This forsnat is documented in detail In section 

5.2.5.2 of the SIS. 

5.2.1.4 SMi.ii£i.-.a£-.LaLiat-lllf£££saass 

The primary difference between the System and General formats Is In 
the placement and content of descriptors. System format and General 
format actual parameter lists are identical if only simple reference 
parameters are passed. All Systeii format descriptors are placed 
directly In the paraijeter list following the PVA of the object being 
described* while General format non-string descriptors are placed 
outside the parai^eter list* The General format parameter list 
contains the PVA of the descriptor as well as the PVA of the object 
being described. 

General format value parameters have the same fom as System format 
value parameters except when the value parameter Is less than one 
word in size or is a pointer to procedure. The General format 

I I on 
fill 
does 
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Use of the General format of the Inter language calling sequence 
requires that a "big" Cl»e. longer than a word) value parameter 
which is passed via a pointer mIII have been copied by the caller. 
The passed pointer Is a pointer to the copy> and the called prograta 
Is free to nrite Into the memory pointed to. The System format does 
not specify whether or not a "big** value parafneter will have been 
copied by the callerp so In this case the called program should not 
write Into ttie mswory pointed to. 

Any procedure or function which is Intended to be callable frow an 

external i!?odyle potentially written in another language should 
accept for that call one (or a subset of one) of the two formats of 
the Inter I anguage calling sequence. Each compiler nsust document 

Hhjch of the tno sequence foriats it accepts,* or state that none of 
Its procedures and functions are externally callable frofli another 

I anguage. 

language Inter lansuage Format Accepted 

ADA -not I nter I anguage callable- 
BASIC -not Interlanguage callable- 
C -to foe determined- 
COBOL System format 
CYBIl System format 
FORTRAN General format 
PASCAL -not interlanguage callable- 



5.2.1.6 Ciiis-£at£al:iaiix-.ta-.4Qaiti£L-Laiiijyias 



A compiler may assume that no call It generates is an interlanguage 
call unless the author of the source program has explicitly 
Indicated that a part I cul ar cal I Is interlanguage. This means that 
each language which supports calls to modules written in another 
language must provide a mechanism within the source language with 
which the author of the source program can explicitly indicate that 
a particular call is Interlanguage. This mechanism must be 
formulated such that the author Is further required to state 
explicitly (by name) which other language is being called. It Is 
then up to the compiler to generate the correct Interlanguage 
calling sequence for the call. Thus the compiler must know which 
languages acceot which calling sequences. It remains the 
r espons I bi i i ty of the author* not the compiler* to ensure that the 
actual and forial parameters of the call are compatible. The 
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5*l*l*b Calls Potantlally to Another language 



compiler lias the rsspon 
the para?Betar IJst a 
cal I a<J 1 anguage* 

These provisions do not 
Inter I anguage calls# 
inter I an gy age calling I 

I nter I angya^e calls t© 
It so chooses. Hote 
Inter I an gu ag e calls » 
I nter I anguage calls via 



sIblHty to generate the correct layout for 
nd parameter descriptors* as expected by the 



require a cofapller or 
tout they do define 
s to be supported. A 
only a Iliilted nuiiber 



language to provide 

restrictions on how 

language nay support 

of other iangyages# If 



that even if a language supports direct 
It is not required to also support Indirect 
dereferenced pointer s-to-procedure. 



5.2.1.6.1 SUPPORT FOR CALLS TO AMQTHER LAMGUAGE 



If a language supports 

and that other lang 
p aran[?eters# than the ca 
calls with sliple refer 
supplied for any object 
calling program has e 
need be passed. An exp 
such as CYSILf which 
procedure declaration 
(descriptor need not 
be passed). 

The calling language is 
for calls Ml th value pa 
the called language ace 
of a mechanis!?? with I 
for each actual paramat 
parameter Is to be pass 
extended reference. 
generate the appropriat 



calls to fiodules written in another language* 

yage accepts calls with sli^ple reference 

I ling language must* at the oiinlfflym* support 

ence parameters. A string descriptor iRust be 

which takes one# unless the author of the 

xpllcitly Indicated that nQ string descriptor 

licit Indication Is possible In languages* 

allow the reference parameter In an external 

to be specified as either fixed type 

be p2lss%^) or adaptable type (descriptor must 



strongly encouraged to also provide support 
raraeters and extended reference parameters if 
epts such calls* This support would consist 
n the source language to expilcitly Indicate* 
er of the Inter language call* whether the 
ed by value* by simple reference* or by 
The compiler then has the responsibility to 
e cal I Ing sequence. 



5.2. Z CALL 



The procedure call Instruction CALLSEG* Reference #115 as 
defined In the CY8ER IBO HIGOS will be used to perform the 
procedure cal I . 

5.3.3 REGISTER SAVING COMVENTIQHS 



For generalized external calls and calls to foraial 
procedures* th? compiler jiay not assume that the called 
procedure will save and restore registers. Any registers 
to be saved must be saved on the stack using the save 
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5»2.3 REGISTER SAVIMG CONVENTIOHS 

«eclianisii of the CALL instruct loo-. 

Internal calls need not use tlie CAliSEG# Reference #115 
instruction. They lay use CALIREI Reference #116 or any 
otl^er code sequence which peets their needs. For Internal 
calls the coipllers have the option whether to save 

registers or ncit. Internal calls Include calls toJ 

al the compllar's own library routines* 

b) nested procedures mi thin the same compilation unit* 

5.2.3.1 iG£fi£ittifia-E2auiEsil-4si££ai-£Lali 

The following Infort^atlon may be required in (taking a call* 
Sotne of the Information is not always required - See footnotes. 

Dynamic to Caller and Callee 

. basic stack control registers CAO# Al* A2)*** 

. parai^eter list pointer CA4)*** 

• static cha I n/di sp I ay* 

• binding section pointer <A3)*** 
« product defined information 
Dynamic to Calleef Static to Caller 

• line number of call (see traceback section)*** 
. number of parameters! XO* bits 32-47)*** 

• descriptor area indicator 

. descriptor area pointer <if any) 
Static to Caller and Callee 

• name of callee (see traceback section) 
« size of display/nesting depth**** 

. fraiie s Ize/ I anguage** 



CYBER. 180 Systeffl Interface Stao^ard 



5-9 
84/07/27 



5.0 COHPIIER km ASSSMiiy CODE CONVENTIONS 
5«2»3.1 Ir^f oriiat Ion Reqy|r«d Across CaH 



« t:ype of frtfflsi e.g* proct fync.# co-proc** 

* Block strycturad latigyages only. 
t* Tracsback mode only. 
■** Required on calls wade ¥\th the I nter language calling sequence 



5.2.4 FUNCTIONS 



A function Is a procedure that returns a value. The 
function value Is In the registers or In memory depending 

on the type of value being returned. Since function 
references are usually part of another expression that is 
being evaluated* It Is generally desirable to have the 

value raturnad in a register. 

If the function value Is a pointer* then the value Is 
returned as a ?VA In AF. A procedure calling a 
pointer-valued function must not save register AF on the 
call. A polntar-val ued function nay have the ring nuf^ber 
field of AF altered by the RETURN Instruction If It Is 
called across a ring boundary. 

If the function value Is a scalar of known length less 
than or equal to 64 bits in lengthy it Is returned right 
aligned In XF. A procedure calling such a function must 

not save register XF on the call. 

If the function value Is double precision or complex then 
the value Is returned In registers XE and XF. XF holds 
the least significant 64 bits of the value. A procedure 
calling such a function must not save XE or XF on the call* 

If the fynctloi value is non-scalar then it Is stored at 
the address defined by the first element of the parameter 
list. The second element of the parameter list specifies 
the first actual parameter. 

A scalar function result is defined as follows! 



CY8IL 

FORTRAN 

COBOL 
PL/I 



character* boolean* Integer* ordinals* 
subranges* cell* pointer. 

logical* integer* real* double precision* 

complex* FORTRAN boolean.* 

cofflp* comp— 1* cooip— 2* boolean. 
IntegerCFIXED READ* reaHFLOAT REALI* 
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5«§ COMPILER km ASSeHBLY .CODE COI^I/ENTIOHS 
5.2..4 FUNCTIOHS 



coifiplexCCOHPLEX) 
BASIC - real* 

• PASCAL - intager* C enumerated typet sub-raf^ge)j 

real 

Scalar function yaluas are returned right aligned In the 
result register. Fill Ti f any) is zero bits. Note that 8 
byte nuparlc Items require no fill* 

* FORTRAN boolean corresponds to a fyll CYBER 180 word *«lthout 
type. It is not ttie same as the boolean type mentioned 

elssMhere In this section* 



5.2,5 PARAMETER LIST 
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5.2. 5 . 1 SlStai-£fl£fflji-EaLai£t£L-LlSt 




CThls is currently docuniented in the CY8IL Handbook# DCS* ARH3078# 
sections 7#1 and 8.3. The following addition must be made to that 
docunientat Ion In order to conforn? to the SIS.3 

for any potentially I nter I anguage call In which a System forsiat 
actual parameter list Is passed that contains only slrople reference 
parameters: The parameter list nust be I mipeTlate! y preceded by a 
flag word whose value is the 64-blt Integer zero. The string 
descriptor prust be included for any object which takes one» unless 
the author of the source program has explicitly indicated that it 
need not be Passed. These restrictions are made to Insure 
compatibility between the release 1.1.2 product set calling 
conventions and those for all future releases* A flag word need not 
precede any other System format actual parameter lists. 
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§•0 COHPILER AWQ 4SSSMBLY CODE COnV£NTIQMS 

5.:2.5«1 System formnt Par abater List 



5*2.5.2 l2fiBt£al«£a£iat-Eat aistat-li^tl; 



The Server a I forsiat paraffleter list niust always foe preceded by a flag 
word* Tha parameter Jlst itself is composed of two parts. Ttie 

f I r_s t part has exactly or^e »iord for each paramete r C Including the 
Pse"ulo par asset er' for non-scalar vaiyed functions). 

preceding the parameter list Is 



va lyi 

zero 



If tlie flag word 
tlien only this first part Is 

PTBSQntp otherwise the second (extension) part must also be present. 
This parameter list extension follows limediatejy after the first 
part of the piraneter list^ and has exactly the sawe length In 
viords. There Is a one-to-one correspondence between word j of the 
first part and -word J of the extension. 

The paraiwater list extension Is required If and only If one or lore 
of the actual parameters is an extended reference parameter or i s a 
pointer-to-procedure value parameter with a static link. 

5.2.5.2.1 FLAG WORD PRECEDING l>ARAHET£R LIST 

The flag Mord i Mediately preceding a General format actual 
parameter list must be present for any potentially Inter 1 anguage 
call. This flag word has the following Internal structure? 

record 

fl3 O..Dffffffffffff C16), 

fZi o..affci6), 

f33 O..OffC16)> 
r ecend 

Field fl rpust always be set to Integer zero. It is reserved for 
future uses. ?^ield fZ has a language dependent value* but may be 
nonzero only If field f3 Is nonzero. Field f3 mast be set to 
integer zero If the parameter list extension is absent* and jnust be 
set to integer one otherwise. Any language accepting calls 
according to the General format must accept inter I anguage calls for 
which field f2 Is zero. An Inter I anguage caller will never be 
required to set field f2 to a non-zero value. If field fZ Is set to 
a non-zero value for an i nter I anguage call* It is the responsibility 
of the caller to set the field according to the expectations of the 
ca I lee. 

5.2.5.2.2 GENERAL FORMAT VALUE PARAMETERS 

If a value parameter is greater than one word In length and Is not a 
pointer-to-procedure* then it is passed using an Identical format to 
that for a reference parameter* 
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3*Q COriPllER AND ASSEMBLY CODE CONVENTIONS 



If a yalye paraieter Is a po inter-to-procedur e then the first part 
of that parameter list entry must contaJri the left Justified PVA of 
the Code Base Pointer of the procedure \n the binding section. The 
second part of the entry <when an extension Is required) «yst 
contain the left Justified PVA of the static link or wust contain 
the MIL pointer If there Is no static link. The 16 bits to the 
right of each of these P^hs is unused and undefined. This can be 
d I agr amiBed ass 



PVA {Code Base) J undefl \ static link/ NIL I undefl 



If a value paraister Is less than or equai to a word In length* then 
a copy of the yatye paratieter Is placed directly in the first part 
of the parameter I 1st right aligned In a i«ord# with sign fill on the 
left for integers and subranges of Integers and zero fill otherwise. 
The associated word In the second part {when an extension is 
required) Is unused and undefined* Note that if a PVA having no 
associated descriptor Is passed by value* then by this rule the PVA 
Is placed directly In the parameter list* right aligned in a word* 
with the word zero-filled on the left. This can be dlagramflied as? 



1 value (right justified) \ \ undefined 



5.2.5,a.3 GENERAL FQRHAT SIHPLF REFERENCE PARAMETERS 

Simple reference parameters are passed either as a PVA or as a PVA 

plus string descriptor. Parameters consisting solely of a PVA are 

placed directly In the first part of the parameter list entry left 

aligned In a word; with the rightmost 16 bits of the word unused and 

undefined. The value of the word In the associated second part (If 

an extension is required) must be the 64-bit integer zero. This can 
be dl agr ammed as J 



^ + + 4 -— , — — -. — «. — 4. 

PVA (object) J undefS J J 



•4 



Simple reference parameters consisting solely of a PVA plus a string 
descriptor are placed directly in the first part of the parameter 
list entry with the PVA left aligned In a word* followed Immediately 
by the two byte long string descriptor. The value of the word In 
the associated second part { I f an extension Is required) iwust be the 
64-bit Integer zero. This can be diagrammed asJ 
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^•O CQHPILEi AND ISSEHBIY CODE COH¥EMTIONS 
3*Zm5.Z*3 general FORHAT SIWPIE REFERENCE PARAMETERS 



I PVA Cobjact) 



J I engthj 

•+^ — + 






5.2«5.a*4 GENERAL FORHAT EXTEHDED REFERENCE PARAMETERS 
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+ — . , . — -^..^ +— -^ + 

I PVA {object) S undefl 

+, — . . «+ 4. 

I PVA {objacti nengthj 



4. — -««. ^^ «««. — 4.««.«^-.-. 4. 

J PVA (descriptor) I undef S 

+ ^ -^ ^ +-■ + 

J PVA (descriptor) I undef t 



5.2.5..a.,5 GENERAL F0R?1AT STf^ING DESCRIPTORS 

A string descriptor is a 16~bit unsigned Integer (0*»65535) 
indicating the length of a string In bytes. When present* It Is 
placed in the prirnary portion of the paramieter list Imwediately 
following (and in the saroe word as) the PVA of the object being 
described* A string descriptor is required for all reference 
parameters to objects of type character # subrange of charactert 
string* substring* or array over a component type of character* 
subrange of character* string* or substring* The string descriptor 
for an array Indicates the length In bytes of a single element. 



5.2.5,2.6 GENERAL FORMAT ARRAY DESCRIPTORS 

The layout of an array descriptor must adhere to the pseudo-CY8IL 

description given below. Note that "extent" refers to the number of 

elements in a particular dlniension* "stride** refers to the distance 
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5«0 CQHPIiER AND ASSEHBIY CODE CON^ENTIOMS 
5.2.5.2*6 GENERAL FORMAT ARRAY DESCRIPTORS 



Cmeasyred in terms of array slepentsi between two consecutive 

elefpents of the same dimension* and "rank" refers to the number of 
dNsenslons In tlie array. Array descriptors nyst be aligned on a 
word boundary. 

arr ay.descr i Ptor = array CI «« rank] of record 

extents ' I nteger:# 
strides Integer* 
1 OMer..boyinds Integer* 
r ecend; 



5.2.5.2.6.1 ii£iis 



For languages such as CYBIL and FORTRAN 7Tf arrays are represented * 

^nd stored as contiguous objectsi stride is a function solely of the • 

extents. HoMever tlie Introduction of array sections in CDC FORTRAN * 

necessitates that an explicit stride be passed in the parameter list * 

since sections need not be contiguous In eemory? tbey fliay have a I 

non-unity increiisent In each dliuenslon of the array* whicli roust be I 

included in t*is calculation of the stride. The stride value for * 

f!?y 1 1 l-di mens ional arrays is calculated differently depending! upon I 

whether arrays are stored columnwise or rowwise. For one I 

dimensional arrays the formulas are equivalent. Note that one * 

dimensional contiguous arrays have a stride of one. I 

t 

For arrays Mtilch are stored coluu?nwlse in faemory (I.e. with the • 

leftiiost subscript varying fastest) the following forujula is useds 1 

4 
I 

i-1 J 



t 4 

strldedl « incr<il * J J ECJ) 

« t 

j«0 



« 



where strldeCI) is the stride In the i-th dimension* incr(l) is the * 
increnient of the I-th dipenslon* and E{0) Is defined to be one* For J 
contiguous arrays* E(j) is the extent of the j-th dlifienslon. For J 
array sections* E{J) Is the extent of the J-th dlrrsension of the J 
contiguous array of which this Is a section* For example if we have I 
the FORTRAN declarations 5 

DIMENSION : (15*30) J 

then for C we haves incr(l)*l* lncr(2)»l* extentCl)«15* J 
extentC2)«30* EC1)«15* E{2)«30* strldetD-l* and str I deC 2) «15. For I 
the sections S 

CC1S10S2, 12S22$3) J 

we haves incr(l)»2* incrC2)«3, €xtentCl)«5* extent<2)«^# EC1)«1§* J 
E(2)-30* sUltieiD'Z^l^Z, and str I de ( 2) »3*1*15«45. 5 
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For arrays *«1i}-gIi are stored rowwise In memory Cl«e« with the 
rightmost subscript varytni fastest) tlie following fori»ula is usedi 



r+1 



strideC J ) « Inert M * J J E< j) 

* « 

J-H-1 

**her8 strldeCI) Is the stride In the l-tli 4\menslonp incrCI) Is the 
Increment of the l-th dimension* r Is the rank of the array# and 
E(r+1) Is defined to be one, for contiguous arrays* £CJ) Is the 
extant of the J-th diirjension* For array sections* ECj) Is the 
extent of the j-th dimension of the contiguous array of which this 
Is a section. For example If we have the FORTRAN declarations 

RQ^yiSfc RC15,3D) 
then for R we have? r=£* lncrCl)*l# incr(2)«l* extentCir«15> 
extentC2l«30^ E<l)=15f E<2)«30# str i deC 1)«30* and strideC2)«l. For 
the sections 

RiUlQtZ, 12s22i3) 
we haves r^Z» incrCl)»2* incrC2)*3> axtentCl)*5* extentca)«4f 
E{1)«15, £C£)=30» str jde(l)«2*l*30*60* and str i deC 2)«3*1«3. 



3.2.6 DATA REPRESENTATION 



The following subsections define the representations of 
data which niust be used If an Iteii of a particular type is 
to be passed between languages, languages !!!ay have types 
beyond these hut data of those types cannot be passed to 
other languages. A language is not forced to provide for 
all of the following data types* 

5.2.6.1 lnt&2S.L 

An integer may occupy 1 to 8 bytes of storage* For 
languages with size allocations dependent on the subrange 
of integers specified* the airsount of storage allocated 
must be the jnlnlmum number of bits needed to hold the 
specified range rounded up to the next full byte* 
Subranges that Include negative numbers must use the 
leftmost bit of the field as the sign bit. Negative 
values are represented as negative two's conipl eitient 
quantities. Subranges of only positive numbers will not 
provide a sign bit. The range of signed Integers Is 
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5«2«6,1 Integer- 



-2**63 < i < 2**63-i« The range of ynsigned integers Is i 
< i < 2**63-X* 

Several languages have an enyiierated type called 
ordinals* These are napped onto the non-negative 
integers* Allocation rules are the sarae as for unsigned 
Integers* If ordinals are passed to a language without 
ordinals they lust be treated as integer values and 
vice-versa-. 

Two sizes of Integers correspond to easily manipulated 
hardware fontsats and are identified as separate subtypes 
of integer to provide for languages with only options for 
half or full word signed integer values* 



5.2.6.1.1 4 BYTE I^^TEGER 

A half integer mIII be represented by a 4 byte C32 bit) 
quantity in the CYBER 180 integer forfuat I.e.* a signed 
two's coiupleeent 32-bit quantity* In which the leftmost 
bit is the sign bit. The range of 4 byte integers Is 
-2**31 < i < 2**31-1. 



5.2.6.1.2 8 8YTE INTEGER. 

A full integer nil I be represented by an 8 byte <64 bit) 
quantity in the CYBtR 180 integer forrpat i*e.> a signed 
two*s conpieiuent 64-blt quant it y# In which the leftmost 
bit is the sign bit. The range of 8 byte integers Is 
-2**63 < I < 2**63-1. 



Fixed length character data will be stored as a sequence 
of consecutive 8 bit bytes. The character set will be 
ASCII. 

5.2.6.3 Esai 

Real data will be represented by an 8 byte (64 bit) 
quantity in the CYBER single precision floating point 
foriuat. All real data wlil foe normalized. 



5-17 

CYBER 180 System Interface Standard 

5*0 CQHPIIER. km ASSEHBIY CODE CONVENTIONS 

5.2.6.3 Real 



5. 2. 6.4 llfiyl2la«££2£iaiaQ 



Double precision data will be represented by a 16 byte 
(128 bit) quantity In the CYBER 180 double precision 
floating point foriaat. It iisust be normal I zed. The PVA in 
the paraneter list points to the first byte of the double 
precision datui* The second (lower precision half) Is 
located at P\^A-»-8 feytes. The sign and exponent fields of 
the loner part are considered to be correct at any given 
time. Input and constant assignment routines are 
responsible for Insur Ing corrct signs and exponents upon 
initial construction of the nuiiber. Double precision 
operations will maintain this foruiat* 



5.2.6.1 Cnialliit 



Complex data will occupy 16 bytes (128 bits) in memory and 
will consist of two reals* where the first real represents 
the "real** part and the second real represents the 
"imaginary** part of the cofflplex quantity* The PVA In the 
paraaseter list points to the first byte of the complex 
datum (the real part). The Imaginary part is located at 
PVA*8 bytes. 



5.2.6.6 a.filJ..iltIfi 



Boolean data occupies a single byte* A value of one 
indicates true and a value of zero indicates false* 

5.2.6.7 EalatSL 

A pointer is a PVA. It occupies six bytes* Pointers f!?ay 
identify data of any o? the other data types. The nil 
pointer Is defined as a PVA with a ring field value of ••F** 
hexadecimal* segment field value **FFF" hexadecimal* and 
address field value "80000000" hexadecimal* 

5.2.7 DATA AlIGNHEHT AND PACKING 

The purpose of the common calling sequence Is to provide 
the ability to pass data between diverse languages* The 
I nter I anguage call Is assumed to represent a snsall 
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5*0 COMPILER AND ASSEMBLY CODE COHVENTIOHS 

§.2,7 DATA ALIGHHeNT km PACKING 



percentage of all calls and generally be used by 

k:r>OMl edgeable ysers* Therefor€# for perforinance In the 
word oriented languages CFQRTRAHj in particular) a 
I east-common-denopilna tor alignment of word Is used* 

Data types villi ch require 8 bytes to store are re<iulred to 
be word aligned to Improve performance* This permits the 
use of the load/store Mord Instructions which are faster 
than load/store of 8 bytes* The space penalty for Mord 
aiigning simple variables is feit to be sisall especially 
since It costs a mBxlmum of 7 bytes pqt procedure If all 
the Mord aligned ItesBs ^re stored contiguously* 



5*2*7.1 EltlmlillS 



Variables may be of any of the above data types* The 
aligni?ent of a particular type must be as follows? 



Data Type 

1-7 Byte Integer 

8 Byte Integer 

Character (String) 

Real 

Ooubie Precision 

Cojppl ex 

8oo1 ean 

Pointer 

5*2*7*2 at£y£JtUL£S 



ignwent 


Byte 


yord 


Byte 


Word 


Word 


Word 


Byte 


Byte 



Structures must begin word aligned* 

Alignment of data to be passed between languages in 
structures must be as follows* 



Data Type 

1-7 Byte Integer 

8 Byte Integer 

Character(Strlng) 

Real 

Ooubie Precision 

Cojnpl ex 

Boolean 

Po inter 



A 1 lgnfl?ent 


Byte 


Word 


Byte 


Word 


Word 


Word 


Byte 


Byte 
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5 •2.7* 2 Structures 



If a byta aligned Item is followed by a wfordl aligned iteia* 

UP to se/en bytss way fee skipped (and left unused) to 
regain mord aligniient. If a byte lte» follows a byte 
iteii# they m^y be In consecutive bytes* 



5 •a, 7* 3 AttMXS 



5. 2,7. 3,1 ARRAYS OF VARIABLES 



The arrays represent a collection of data IteiiBS of one 
uniform type. Arrays must be word aligned If tlie data 
type they contain Is viord aligned. Unless required by an 
external standard all languages should store arrays with 
the rightfpost subscript varying fastest. FORTRAN* for 
example* is constrained by ANSI standards to store arrays 
with the leftiost subscript varying fastest* If a user 
passes a mul tl d I fiens I onal array between languages with 
different storage orders* it Is the user's responsibility 
to handle this. Arrays must be byte aligned if all of the 
constituent elafpents are byte aligned. The parameter list 
PVA identifies the first element of the array. Subsequent 
elements »ust be contiguous and In ascending storage 
address sequence. 



5.2.7.3.2 ARRAYS OF STRUCTURES 

If any element of the structure Is required to be word 
aligned* each array elensent fpust start on a word boundary* 



5.2.7.3.3 COIiMQN StOCKS 



Iteps within common blocks must be aligned consistently to 
achieve i nter I anguage communication. Common blocks will 
begin word aligned. Alignment of data within the common 
block will be the same as for structures. 



5.2.8 LANGUAGE INTERCHANGE TABLE 



The following table shows the possible parameter types 
that may be used between languages. If a letter appears 
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5.2.8 LANGUAGE IMTERCHANGE TABLE 

at an Intsrsectlon In the table* that type ^ay be passed* 

Types are encoded as followss 

J » l-3# 5-7 Byte Integer « ordinal 

H « 4 Byte Integer 1*8 Byte Integer 

C - C^iaracter (string) R « Real 

« Doyfele Precision Z « Complex 

8 « Boolean ? « Pointer 

A = Array S « Structure 

All * all types of the language 

C a M e e 

CY8IL PASCAL(¥) FORTRAN C080L PL/I BASIC 
Cal ler 

CYBIL AH HIJCBPSAOR ICARD HICBSARD HICBPSAR CR 

PASCALC!^) HIJC8PSA0R ALL ICA HIC8SA HIC8PSA C 

FORTRAN ICARO ICA AH ICRDA ICROZA CRA 

COBOL HICBSARO HICBSA ICRDA All HIC3R0SA CRA 

PL /I HICBPSAR HICBPSA ICRDZA HIC8R0SA All CRA 

BASIC CR C CRA CRA CRA AH 

Notes J 

1) PL/I may not have a double precision data type due to 
possible high overhead in supporting the maxlfuujn 
precision rules. This will be determined later* 

2) If arrays are permitted between two languages^ the 
type of the array Is restricted to the types of 
variables that are pernsltted between the two languages* 

3) Arrays of characters in BASIC cannot be passed to 
other languages* and vice versa* 

5.2.8.1 g)Lt&U^&si^lUt&LQ\l^Q2Si 

The language Interchange table defines the paraineter types 
that can be used between pairs of languages* In many 
cases restrictions exist because a particular language 
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5.2 •8*1 Extended Intarcfiange 



Iscks a tlat^ type. For axamplef 8ASIC lacks Integer type 
si net it stores them as reals. In iiany instances the type 
;?f!is!Batches could be m^pp-B^ by interface code between the 
procedure calls. The following leclianlsw Is proposed to 
support such fnapplng when and if it becomes a reqy If aiaent* 



In order to lap parameters* an Intercept routi 
control from the caller* map things and pass c 

the callee. The reverse may be necessary upon 
The user should not have to be aware of the ac 
the interface routine or invoke it directly. 
tl^ls* the loader eust have a mechanlsii for det 
ne€4 for an Interface routine and Inserting sa 
cali/return path* The Insertion mechanism can 
to the one used for Analyze Prograoi Oynaplcs i 
Detection of the need for Inserting the Interf 
can be done nith load 1 1 nie argu^isent checking m 



ne must gain 
ontrol to 

return* 
tlvltles of 
To achieve 
ecting the 
tie In the 

be similar 
APO). 

ace routine 
echani sms. 



For each pair of languages CX and Y) where interface 
flapping Is desired* loader tables defining relevant 
information about actual and formal parameters must be 
defined. A routine (activated during loading by the 
loader If a call from X to Y Is found) will coppare the 
actual and formal parameter lists to determine if mapping 
Is required. If not* the loader simply links as usual* 
Otherwise* a X to Y mapping routine from a library Is 
Inserted Into the linkage by the loader. 



The X to Y mapping routine receives the actual 
parameter list Information from the loader* 



and formal 



The caller Information is obtained by giving the P address 
of caller to a loader service routine which returns a PVA 
if the actual parameter list inforasation for the current 
call. The callee Information is obtained by giving the 
code base pointer of callee to a loader service routine* 

The mapping routine uses this Information to transform the 
parameter list and/or data representations before calling 
the callee* yhen the caliee returns* the mapper will 
receive control to do any mapping on return parameters* 



5.2.9 REGISTER CALL FUNCTIONS 



In many languages there exist commonly used sets of 
functions {for example* mathematical functions) for which 
It is more efficient (though less general) to pass a 
limited set of parameter values via registers* Up to 
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5^0 COMPILER AND ASSEHBIY CODE CONVEHTIOHS 
5*2.9 REGISTER CALL FUI^CTIQI^S 



elgfit <64 bit values) can be passed Irs registers X2 - X9« 
Tl^e first paraneter value mouI<j be in X2# the second in 
X3> etc. If a double v?ord value (siy* double precision) 
is required* It uses two consecutive registers* The 
specific register used for a routine aiay be inferred from 
"tiie type of the paraineter. For exansple* SQRTIX) will use 
X2 while DSQRTCD) i# I I I use X2 and X3. These rules apply 
to the folloi^fn-g -data types as paraieters? 

1-7 feyta integers 

8 byte Integers 

Real 

Doubt e Prec I si on 

Cojup J ex 



Return registers for 

must not be saved In 



register call 

cal I Ing them* 



functions {see 5*2*3) 



No rules are specified for character* boolean or pointer 
data pending Identification of functions using these 

argufient types that are of general utility* 

The register call entry point is not bound by the 
conventions of the coii^fnon cal I Ing se<iuence* 

Ail register call functions Intended for general use wust 
also offer an entry point that accepts the comiion calling 
sequence <5.2 above) and ref erenceabi e by a CALLSEC 
i nstructi on. 



5 . 3 i!ii£aaEQayai.£iL£-ys4S£ 



Interproduct file sharing between executing subsystems 
will be addressed. It will specify under what conditions 
a product will be able to perform I/O on a file declared 
by another product* It will also address closing and 
flushing of files at Job step ter??? I nat ion when 
Inter I anguage files are being used* 



5*4 iIQgA££-!!Mi££ll£MI 



Purpose 

In order that user object code froii different coinpllers 
can co-exist In one job step while using a liiiiited number 

of segments* certain conventions must be observed* 
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5.0 COMPILER mo ASSEMBLY CQOE COMVENTIONS 

5.4 STORAGE MANAGEHENT 



Each user will have a limited nuinber of segments. This 

siearjs that object code from different compilers must be 

ahle to share certain data segrients* 



5.4.1 STANDARD STACK FRAHE 



This section describes the standard stack frasie which *«lll 
be set up In canjunctlon v^lth the CALL Instruction. The 
purpose of standardizing tlie stack frame layout Is to 
provide common traceback and debugging Interfaces. At the 
sane time* allowance Is made for a mlnlmuai frame for 
languages such as batch mode FORTRAN* with extensions for 
the complexity of languages such as PL/I. 

A stack frane consists of two areas? 

1. The save area. 

2. The **envir onmenti I" area. 

The save area beNngs to the caller* the '•env Iromaental** 
area belongs to the callee and botti exist In the 
appropriate rings. 



5.4.1.1 ItiiisMlSis 



Traceback Is considered to be the lowest level of 
debugging and as such requires the support of both the 
loader and the compilers/assembler. Minimum traceback 
Information will always be produced to facilitate some 
tracing from within the system. 

The compilers/assembler will produce traceback tables In 
the object module which correlate object-code address of 
entry points and calls with source-code procedure names 
and line numbers. The loader will maintain the relation 
of these object code addresses. When traceback Is 
required* these traceback tables* plus the stack* will be 
interpreted to give the source-code names and line numbers 
associated with the PVAs obtained during traceback. In 
full traceback mode entries will exist for each line or 
source statement; In minimum traceback mode only entry 
points and calls are eionltored. 
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5«4«1»2 Static Chain vs» Display 

CSee Glossary for definitions.) 

It Is not the Intention of this standard to dictate 
whether coropllad coda will raference globals via the 
static chain or a display. Either Is permitted and nust 
be maintained by tha soft^iare. NoteJ this only applies to 
calls to a ntstsd proctdyre and hence Is I ntr al anguage. 

§•4.2 CHAINS OF ON~CONDITION PROCESSORS 

Softi^are conventions for a standard on-conditlon processor 
chain format are required to ensure that on-cond It I on s can 
be processed correctly* 

The on-condltlon flag CQCF) In the save area Is used to 
indicate that the stack frame has associated on-condltion 
processors. The first eight bytes of the stack frame 
{pointed to by the current stack fraiwe (CSF) of the save 
area) are reserved for the head of the on-condltion 
processor chain. All object code generators must 
accommodate the head of chain reservation. If the OCF Is 
set In the save btb^* the eight bytes pointed to by CSF is 
the head of the on-conditlon processor chain. If the QCF 
is not setj the contents of the eight bytes is undefined. 

5.4,3 DYMAHIC NON-STACK STORAGE 



5.4.3.1 OiQiii£«ls.ai^ata 



NOS/VE provides the capability of creating new segments 
during product execytJon. Since this increases the number 
of segments In active use and potentially causes a 
performance degradation^ its use should be limited to 
situations where the alternatives are less satisfactory. 
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5.0 COMPILER AND ASSH^^BIY CODE CONTENTIONS ' 
5»4«3«2 Fixed-Position Oynawlc Storage 



5 * 4« 3 • a £ii£il=£aaitliia-.fliaailii-Statmi2t 



Ttie fyndamental support for f I xed-pos J tlon dynaiiic storage 
allocatian Is provided by the CY8IL AltOCATE statement 
¥lth no IN option. 

Products coded \n CY8II and need I rig f I xed-pos 1 1 1 on dynaiRic 
storage should use the ALLOCATE statement directly* 
Products not coded in CY8IL and needing fixed-position 

dynamic storage may either! 

1) include CY8IL subroutines containing ttie appropriate 
ALLOCATE statements* or 

2) use a set of comiion routines wliicti will provide a CHN 

compatible interface to the ALLOCATE statement. 



5 « 4» 3. 3 jiii:iikis=£asitia!i-.l}iQail£-Stfitiat 



Variable-position dynamic storage Is not currently planned 
for support. 



5*5 (IQ!iiQI:i«Sy££QEI-.B0f2liL£l 



This section will daflna !T»odules which i^lJI be available 
for general use. 

Hath Routines 

For a detailed account of the math routines to be provided 
see €180 Co??»!ion Hodules Hath Library <CliML) ERS with DCS 
log ID S2929. The routines will offer both a register 
calling sequence and the common calling sequence. Entry 
point names *iil1 ineet the specifications of section 4.1#1» 

Numeric Conversion Routines 

Routines ^\\\ be provided for all products (con^pller or 
runtime systems) to perform numeric input and output 
conversion. This will ensure that the same numeric 
representation matches the same internal bit value by all 
processors. See also C180 common laodules math library 
<CHHL) ERS with DCS log 10 SZ929, and CHML 
Assembly-language Support System ERS with DCS log ID S3410» 
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5.5 camon sopport moooies 



TO 



FROH 

Integer 

Real 

t o n g r e a I 

ASCII 

ASCII 

{ nondec* I 

BOP* 

Unpacked 
decimal 
t r a i I I n g 
s I gn 

combi ned 
fioll 8r I th 

Number 170 



I 


R 


L 


n 


e 





t 


a 


n 


e 


1 


Q 


g 




r 


e 




e 


r 




a 
1 



XCl) 



A BOP* 


Unpacked 


Nufuber 


S 


tral 1 ing 


170 


c 


sign 




I 


combina- 




I 


tion 




Jr^ondec* ) 


hoi leritti 





X X 
X<1) 
X(l) 
XCl) XC2) 



* Includes all BDP types exceptt a I phanufner i c 

(1) there are additional routines for handling real and longreal conversions 
to and from asci I In olecemeal fashion 

(2) translation* movet etc# 



Uti I ities 

A set of common uti i I ties will be provided to carry out 
the fo Mowing functionss 



Diagnostic Handling - the forfpatting of diagnostic 
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5.0 CQHPILER AHO ASSEMBLY CODE COHVENTIOHS 
S.5 CQMMOri SUPPORT HOOUiES 



lines of output and the construction of the diagnostic 

I i s 1 1 n gs • 

Source listing formatting - the forjitttlng of the 
sourca listing including output of the source Mnes to 
a print file. 

Storage wap/Attr I bute/Cross Reference listings - the 

foraiattini of this listing and output of Its contents 
to a print file, 

Conpiier Usages Statistics - the generation of usage 
statistics iTsessages. 
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6,0 SIQSSARY OF TERHS 



6.0 aLQSSi^SI.fi£«I£EM 



In writing the Syste?u Interface Standard It becanie 
necessary to clarify the jneaning of certain Mords. This 
glossary contains those i^ords which required 
clarification. The list will be extended* 

-a- adjective 
~n~ nourk 

-V- verb 

Binary -a- Of base 2» Not to be used without 

qualification to jsean the object code 
output froB? a compiler* Mote object 
code files are one of fliany different 
forras of binary files. 

Boolean -n- Data type which can hold the values 

''true** or "false*** 

FORTRAN -n- Boolean data but required to occupy a 
Boolean full computer word. 

Diagnostic -n- Generally a part of a larger entltyf 

such as listabla outputs as opposed 
to an error message* i^hlch Is 
generally a summary of a command* 
Diagnostics are generally Issued by a 
nuisber of the product set# such as a 
compiler* See also - error message* 
Examples A compiler may provide a 
single error fiessage telling how many 
errors occurred during compilation 
and produce a diagnostic for each 
compi I at Ion error* 

Display -n~ A mechanism for accessing global 

variables of a program using a table 
of stack frame pointers; one pointer 
for each accessible scope and one 
table for each active scope* 

Error l^essage ~n- Generally a summary of a coR^mandf as 

opposed to a diagnostic^ which Is 
generally a part of a larger entity* 
such as listable output* The error 
siessage Is generally Issued by the 



CYBER 180 Systefi l?iterftce Standafd 



6-2 



6.0 GLOSSARY OF TERRS 



Invoke 



Job Step 



~¥~- 



-H' 



load Hodyie 



-n~- 



Object Module 



Object Prograf 



-n- 



-n- 



processC Ing) 



Processor 



-V- 



-n- 



Product 



Product Set 



record 



~n- 



-n- 



-n- 



operating systeti or by a product via 
tbe operating syste«» See also - 
diagnostic for an example. 
Applies only to spirits^ witches* 
etc» Procedures are called* 



A job step Is the work done as a 
result of a single coiPBiand in tNe 
deck/file* Job steps execute 
se<iuent i al I y within a job. 



job 



Object Information produced by object 
library generator and input to the 
loader or back into object library 
generator* Load nodules are designed 
to facilitate processing by the 
loader • 

An object module is a unit containing 
code and/or data definition that is 
produced by compilers* 

An object prograi is a set of object 
«»?odules organized to pttft^vm some 
specific function {e*g** compile 
COBOL statements). An object program 
Is prepared for execution by the 
1 oader * 

CowputHng)* Unrestricted to mean 
either hardware or software* 

Restricted to hardware CPU or PPU* 
May be used for software if 
sufficiently <3ualified# e.g. language 
processor* 

Any part of the standard software 
yhich is covered by the System 
Inerface Standard* 



That part of the System which 
part of the Operating System* 



Is not 



A unit of data on a file* e*g* a 
card image* line image* Hot to be 
used wl t hout qual If i cat i on If meanin 
a "CY8IL" record or ••SCL*' record* 
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Standard -n~ 

Statlc chain -0- 

Systsm -n- 

Task -n- 



Plur al-Standard not Standards whan 

used \m the sense of the Systew 
Interface standard, 

A fuechanisip for accessing giobal 
variables of a progran ysing links 
through the stack frames* 
All products Cq»y») operating as a 
%ihole - to be di stingy i shed from 
Operating System. 

A task Is an Instance of eicecution of 
an object program. Hultlple tasks 
oan execute within a single job 
step. Each task has Its own address 
space (set of roenjory segments). 
Tasks may be initiated either 
synchronously or asynchronously to 
the i n 1 1 i at ing task. 
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